Как ковенанты Kaspa используют DAA-счёт как программируемые часы

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

Ковенанты Toccata в Kaspa не имеют доступа к метке времени вашего телефона или централизованному оракулу. Что они действительно имеют — это DAA-счёт — счётчик на уровне протокола, который увеличивается с каждым блоком в DAG. Скрипты ковенантов считывают age UTXO: разницу DAA-счёта между текущим виртуальным блоком и моментом создания UTXO. Когда age пересекает порог, открывается путь траты с временным замком.

Этот один механизм — возраст UTXO, измеренный в единицах DAA-счёта — является часами за каждой функцией ковенанта с таймером в Kaspa: задержки вывода, таймеры наследования с механизмом «мёртвой руки», окна споров при эскроу и автоматические релизы. В этой статье объясняется, как это работает, где это используется и каковы компромиссы.

DAA-счёт: внутренние часы DAG

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

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

Примитив возраста в скриптах ковенантов

Когда транзакция Kaspa создаёт UTXO, этот UTXO штампуется DAA-счётом блока принятия. Когда будущая транзакция пытается его потратить, DAA-счёт виртуального блока сравнивается с этим штампом. Разница — это age UTXO.

Скрипты ковенантов проверяют это с помощью опкодов интроспекции транзакций. Контракт может требовать age >= N перед тем, как позволить определённый путь траты. Если условие не выполнено, этот путь просто недоступен — каждый узел в сети отклоняет транзакцию.

; Концептуально — не точный синтаксис:
; Путь «complete» становится доступен для траты
; только после того, как UTXO достигнет порога задержки
entrypoint complete():
    require(age >= delay)
    ; место назначения было зафиксировано во время initiate()
    ; подпись не требуется — безопорный путь

Это даёт разработчикам ковенантов фундаментальный строительный блок: временны́е ограничения, обеспеченные консенсусом доказательства работы, а не третьей стороной.

Как хранилище использует возраст: три временных замка

В Kaspa Safe контракт ковенанта (vault.sil) реализует три различных временных замка, все из которых управляются возрастом UTXO.

Задержка вывода. Когда вы инициируете вывод из хранилища, контракт переходит из режима VAULT в UNVAULTING и фиксирует адрес назначения в состоянии цепочки. Путь complete(), который фактически высвобождает средства, требует age >= delay. В течение этого окна любой, у кого есть тревожный ключ, может отправить cancel(), чтобы вернуть UTXO в режим хранилища.

initiate(hotSig, destPk)    →  VAULT → UNVAULTING   (age сбрасывается в 0)
cancel(alarmSig)             →  UNVAULTING → VAULT   (age сбрасывается в 0)
complete()                   →  UNVAULTING → dest    (age >= delay, нет подписи)

Задержка выбирается владельцем хранилища при создании — 24 часа для активных пользователей, 72 часа для более глубокого холодного хранения. Критически важный момент дизайна: complete() не требует подписи. Это безопорный путь. Как только задержка истекает, любой может его отправить. Средства идут точно туда, куда зафиксировал их initiate; никто не может их перенаправить.

Таймер наследования. Хранилище имеет отдельный параметр inheritDelay, обычно составляющий недели или месяцы. Если владелец не делает checkin() в течение этого окна, открывается путь наследования. Флаг autoInherit выбирает режим:

• autoInherit == 1: inheritAuto() — безопорный, требует age >= inheritDelay. Любой может отправить; средства идут на жёстко закодированный адрес наследника.
• autoInherit == 0: inheritSigned(heirSig) — требует подпись наследника и age >= inheritDelay. Наследник должен активно заявить права.

Если владелец установит heir в 32 нулевых байта, наследование полностью отключается.

Сигнал активности (heartbeat). Путь checkin() потребляет UTXO хранилища и пересоздаёт его по тому же адресу с теми же параметрами. Возраст нового UTXO начинается с нуля. Средства не перемещаются, параметры не меняются, но часы сбрасываются.

checkin(hotSig)  →  VAULT → VAULT  (age сбрасывается; таймер наследования запускается заново)

На практике Kaspa Safe отправляет напоминания, когда прошло 80% времени inheritDelay — через Telegram, электронную почту или веб-уведомления — чтобы владелец знал о необходимости сделать checkin до активации пути наследника.

Как эскроу использует возраст: окна споров и тайм-ауты

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

Окно споров и автоматический релиз. После финансирования сделки эскроу у покупателя есть окно (измеряемое в единицах DAA-счёта) для подачи спора. Если спор не поступил и age >= disputeWindow, срабатывает путь autoRelease(): безопорная транзакция, которая отправляет все средства продавцу. Пресеты варьируются от 24 часов для OTC-сделок до 168 часов для физических товаров.

autoRelease()  →  ACTIVE, age >= disputeWindow  →  средства продавцу  (безопорно, применяется комиссия)

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

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

timeoutToBuyer()   →  DISPUTED, timeoutTo==0, age >= arbiterDeadline  →  покупателю  (без комиссии)
timeoutToSeller()  →  DISPUTED, timeoutTo==1, age >= arbiterDeadline  →  продавцу  (без комиссии)

Механизм тайм-аута — это целенаправленная страховочная сеть: даже если все сервисы и все люди исчезнут, контракт в конечном итоге высвободит средства сам. Дизайн с нулевой комиссией гарантирует, что мотивированная третья сторона (или сам бенефициар) сможет отправить транзакцию без considerations по стоимости.

Как Kaspa Forge отслеживает эти часы

В цепочке ковенант безоговорочно обеспечивает временные замки. Вне цепочки платформа Kaspa Forge наблюдает и оповещает.

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

• Владельцу хранилища: «80% вашей задержки наследования истекло — сделайте checkin сейчас, чтобы сбросить таймер.»
• Владельцу хранилища: «Был инициирован вывод. У вас есть X часов для отмены с помощью вашего тревожного ключа.»
• Покупателю в эскроу: «50% окна споров прошло. Отпустите или оспорьте до автоматического релиза.»
• Контакту наследника: Уведомление по электронной почте, что путь наследования вот-вот откроется.

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

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

DAA-счёт как часы не является совершенным. Вот реальные ограничения.

Точность vs. реальное время. DAA-счёт увеличивается примерно пропорционально скорости генерации блоков, но это не настенные часы. При 10 BPS «24-часовая» задержка составляет примерно 864 000 единиц DAA-счёта. Фактическое истекшее время может отклоняться на минуты или даже часы в зависимости от колебаний хешрейта сети, поскольку регулировка сложности сглаживается через окна в 2 641 блок, а не отслеживает реальное время. Для целей безопасности — окна обнаружения кражи, периоды споров — эта дисперсия приемлема. Для точного планирования — нет.

Нет обратного отсчёта, видимого в цепочке. Нет оракула в цепочке, который говорит «у этого UTXO осталось 4 часа». Узлы вычисляют возраст во время валидации, но оставшееся время для конкретного пути — это вычисление на стороне клиента: текущий виртуальный DAA-счёт минус DAA-счёт UTXO. Интерфейс Kaspa Forge вычисляет это в браузере на основе данных от живого узла.

У checkin есть стоимость. Каждый checkin() — это транзакция, потребляющая небольшое количество KAS в виде комиссии сети. Для владельцев хранилищ с короткими значениями inheritDelay нагрузка от checkin может накапливаться. Платформа отправляет напоминания, чтобы свести к минимуму ненужные checkin, одновременно предотвращая случайные срабатывания наследования.

Возраст сбрасывается при любой трате. Если владелец хранилища инициирует вывод — даже тот, который планирует отменить — возраст UTXO сбрасывается при его возврате в режим VAULT. Это означает, что отменённый вывод также сбрасывает таймер наследования. На практике это редко проблематично: если вы активно используете хранилище, вы, очевидно, живы. Но стоит понимать это взаимодействие.

DAA-счёт, а не высота блока. Это, на самом деле, преимущество по сравнению с цепями, использующими чистую высоту блока. В blockDAG с параллельными блоками высота блока сама по себе неоднозначна — с чьей точки зрения? DAA-счёт, как слитый счёт всех вознаграждённых блоков, обеспечивает канонический монотонный счётчик, работающий независимо от топологии DAG. Это одно из тех качеств, что делает ковенанты с временными замками возможными именно в Kaspa.

Собираем всё вместе

DAA-счёт — это не просто параметр эмиссии или ссылка на сложность. Это пульс каждого финансового контракта на основе ковенантов в Kaspa. Защитная задержка хранилища от кражи, механизм наследования «мёртвой руки», окно споров в эскроу и автоматический релиз после бездействия — всё это опирается на один и тот же фундаментальный примитив: require(age >= threshold).

Чем больше блоков производит Kaspa, тем точнее часы. При 10 BPS 24-часовое окно охватывает примерно 864 000 блоков — гораздо точнее, чем ~144 блоков в день у Bitcoin, без компромиссов в безопасности, связанных с более длительным временем генерации блоков. Компромисс в том, что часы ковенантов измеряют блок-время, а не реальное время. Для финансовых контрактов, которые строит Kaspa Forge — обнаружение кражи, наследование, разрешение споров — этого более чем достаточно.

Понимание этого одного механизма раскрывает логику за каждой функцией с таймером в Kaspa Safe, Kaspa Escrow и более широкой экосистеме ковенантов Toccata.