Как работают ковенанты Kaspa: программируемые правила расходования на PoW

Стандартная транзакция Kaspa блокирует средства за публичным ключом: тот, кто владеет соответствующим приватным ключом, может потратить монеты. Эта модель подходит для базового кошелька — но она не способна выразить правило вроде «этот вывод должен подождать 24 часа» или «если я не подам сигнал в течение шести месяцев, отправь средства моему наследнику». До Toccata единственным способом обеспечить такую логику было отдать ключи кастодиальному сервису.

Ковенанты меняют это. Ковенант — это условие расходования, привязанное к UTXO, которое ограничивает не только *кто* может подписать транзакцию, но и *как* структурированы её выходы и *когда* разрешено расходование. В Kaspa обновление Toccata принесло эту возможность в основную сеть, обеспечив on-chain скрипты, которые реализуют конечные автоматы с несколькими путями — без посредников, без мультиподписного кастодиана, без необходимости доверять третьей стороне.

В этой статье мы разберём механику работы ковенантов Kaspa, а также покажем, как Kaspa Safe и Kaspa Escrow строят на их основе готовые продукты.

Какую проблему решают ковенанты

Рассмотрим типичную дилемму самостоятельного хранения. Вы держите KAS в стандартном кошельке. Если ваш горячий ключ скомпрометирован, злоумышленник получает мгновенный доступ — никакой задержки, второго фактора или окна для отмены. Можно использовать аппаратный кошелёк, но средства всё равно потрачиваемы одной транзакцией, как только ключ поставил подпись.

А теперь представьте другую конструкцию: средства лежат в on-chain скрипте, который говорит: «чтобы потратить эти монеты, ты сначала должен объявить о своём намерении, затем подождать N блоков, затем завершить вывод — а в период ожидания отдельный тревожный ключ может отменить транзакцию». Это и есть ковенант. Правила обеспечивает каждый узел Kaspa, валидирующий blockDAG, а не сервер, которому приходится доверять.

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

Анатомия ковенанта Kaspa

Язык скриптов: Silverscript

Ковенанты Kaspa пишутся на Silverscript (^0.1.0) — языке, созданном специально для скриптовой виртуальной машины Kaspa. Файл Silverscript (.sil) определяет три вещи:

1. Параметры — публичные ключи, значения задержек, адреса и флаги, задаваемые один раз при создании ковенанта. Для хранилища это: горячий ключ, тревожный ключ, длительность задержки, публичный ключ наследника и настройки наследования. 2. Состояние — компактная структура, хранимая внутри самого UTXO. Когда транзакция расходования удовлетворяет путь ковенанта, новый UTXO переносит обновлённое состояние дальше. 3. Точки входа (пути расходования) — каждый путь указывает, какие подписи требуются, какой переход состояния происходит и куда должны попасть выходы.

Компилятор выдаёт байткод, который узел Kaspa валидирует. Как только средства отправлены на адрес ковенанта, скрипт и его параметры становятся неизменяемыми.

Конечные автоматы on-chain

Ковенант — это конечный автомат, живущий внутри UTXO. Каждая транзакция расходования должна пройти три проверки:

• Авторизация — предоставляет ли транзакция требуемые подписи или выполняет безключевое условие (например, UTXO переждал тайм-аут)?
• Переход состояния — допустимо ли текущее состояние для этого пути? Нельзя complete вывод, если хранилище всё ещё в режиме VAULT; сначала нужно initiate.
• Ограничения на выходы — соответствуют ли выходы транзакции тому, что требует путь? Путь complete может отправить средства только на адрес назначения, зафиксированный в состоянии при initiate.

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

Тайминг на основе DAA

Высокая частота блоков Kaspa (10 блоков в секунду) и её DAA (алгоритм корректировки сложности) обеспечивают надёжные, устойчивые к манипуляциям часы для тайм-аутов ковенантов. Задержки измеряются в приращениях DAA-счёта, а не в отметках настенных часов. Окно DAA охватывает 2641 блок, сглаживая локальные отклонения — ни один майнер не способен существенно ускорить тайм-аут, манипулируя временными метками блоков. Задержка в N единиц DAA соответствует предсказуемому реальному промежутку времени.

Вычислительный бюджет

Каждый путь ковенанта потребляет вычислительный бюджет — ограничение на объём вычислительной работы, которую может потребовать валидация одного UTXO. Это предотвращает атаки типа «отказ в обслуживании», когда патологический скрипт заставляет узлы вступать в дорогие циклы. Переходы хранилищ Kaspa Safe потребляют 20 вычислительных единиц; путь миграции с двойной подписью migrate — 30. Транзакции Kaspa Escrow используют 40 единиц. Эти ограничения обеспечиваются сетью.

Kaspa Safe: ковенант хранилища на практике

Kaspa Safe — это некастодиальное хранилище для держателей KAS, построенное целиком на ковенанте Toccata под названием vault.sil. Контракт реализует конечный автомат с семью путями:

Полезная нагрузка состояния — два поля: mode (0 = VAULT, 1 = UNVAULTING) и dest (36-байтовый скрипт-публичный ключ с префиксом версии — адрес назначения вывода). Вызов initiate записывает адрес назначения в состояние — его нельзя изменить до тех пор, пока вывод не будет завершён или отменён.

Ключевое свойство конструкции: безключевые пути (complete, inheritAuto) может транслировать *кто угодно* — включая сервер Kaspa Forge — поскольку средства могут уйти только туда, куда уже предписывает ковенант. Сервер может инициировать транзакции, но никогда не касается ключей и не контролирует адреса назначения. Если Kaspa Forge исчезнет полностью, open-source утилита vaultctl CLI и распечатанная карточка восстановления позволят взаимодействовать с хранилищем напрямую через любой узел Kaspa (v2+). Подробности — в разделе как работает хранилище.

В продакшене скрипт ковенанта компилируется на этапе сборки и встраивается как в клиентский WASM-модуль браузера, так и в серверный бинарник через Rust-макрос include_str!. Вся подпись происходит на стороне клиента — в браузере или в обёртке Tauri для Android; приватные ключи никогда не покидают устройство пользователя. Сервер — это тонкий RPC-мост к узлу Kaspa, который запускает 10-секундный цикл наблюдения для алертов и автоматических безключевых транзакций.

Kaspa Escrow: ковенанты для P2P-сделок

Kaspa Escrow использует отдельный ковенант escrow.sil для хранения средств в одноранговых транзакциях. Контракт реализует конечный автомат с десятью путями и двумя состояниями: ACTIVE (сделка в процессе) и DISPUTED (ожидает арбитража).

Кооперативные пути позволяют сторонам разрешить ситуацию без внешней помощи:

• release — покупатель подписывает, средства идут продавцу.
• refund — продавец подписывает, средства идут покупателю.
• mutual — обе стороны подписывают, выходы гибкие (но выход с комиссией обязателен, чтобы обойти структуру комиссий было нельзя).

Спорные и арбитражные пути активируются, когда сотрудничество невозможно:

• dispute — покупатель инициирует эскалацию, переводя UTXO в состояние DISPUTED и запуская дедлайн для арбитра.
• arbitrateToBuyer, arbitrateToSeller, arbitrateSplit — назначенный ключ арбитра разрешает спор.

Пути тайм-аутов (без ключа) решают сценарий «арбитр исчезает»: после дедлайна на основе DAA средства направляются заранее определённой стороне, выбранной при создании сделки — без подписи, без зависимости от сервиса.

Ключевой инвариант контракта: ни один путь расходования — даже арбитражные — не может отправить средства куда-либо, кроме {buyer, seller, feeSpk}. Арбитр решает, *как* разделить средства, но не имеет никаких полномочий перенаправить их в другое место. Это обеспечивается на уровне консенсуса каждым валидирующим узлом. В этом структурное отличие от кастодиальных эскроу-ботов в Telegram, где оператор физически владеет средствами.

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

Ковенанты в Kaspa мощные, но несут реальные ограничения:

• Потолок вычислительного бюджета. Сложная многоподписная логика ограничена. Добавление большего числа путей или более тяжёлой валидации рискует упираться в вычислительный лимит сети. Текущие конструкции укладываются в бюджет с запасом, но выразительность конечна.

• Зрелость Silverscript. Язык версии ^0.1.0 — специализированный и работоспособный, но молодой. Инструментарий, документация и покрытие сторонними аудитами ещё развиваются. Контракт Kaspa Safe находится на версии v3; пересмотр v4 запланирован перед внешним аудитом.

• Ограничения на размер состояния. Каждый UTXO ковенанта несёт небольшую полезную нагрузку состояния (флаги режима, байты адреса назначения, публичные ключи). Сложные метаданные хранятся off-chain. Это сохраняет лёгкость валидации, но ограничивает то, что контракт может «запоминать».

• Статус аудита. На момент написания ни vault.sil, ни escrow.sil не проходили внешний аудит безопасности. Контракты имеют более 25 нативных тестов эквивалентности виртуальной машины и набор из 52 кейсов самотестирования (escrow), но «протестировано разработчиками» — это не то же самое, что «проверено независимо». Версия v4 Kaspa Safe предназначена для внешней проверки.

• Ограничения бета-продукта. Kaspa Escrow ограничивает размер сделок диапазоном 50–10 000 KAS в период беты, а вердикт ИИ-медиатора не является обязательным — он исполняется только если одна из сторон его подписывает или вмешивается живой арбитр. Это осознанные ограничительные меры.

• Отсутствие вычислений общего назначения. Ковенанты — это не тьюринг-полные смарт-контракты. Нет персистентного хранения между UTXO, нет повторного входа, нет межконтрактных вызовов. Каждый UTXO — изолированный конечный автомат. Это ограничивает выразительность, но устраняет целые классы эксплойтов, от которых страдают системы на основе аккаунтов.

Честное резюме: ковенанты в Kaspa дают вам программируемые, обеспечиваемые консенсусом правила расходования без передачи ключей кому бы то ни было. Компромисс в том, что логика должна укладываться в фиксированный вычислительный бюджет и выражать себя через небольшой конечный автомат на каждый UTXO. Для хранилищ, эскроу и наследования — сценариев, где важно «куда могут уйти деньги» больше, чем «что контракт может вычислить» — этот компромисс работает.