Kaspa Deposit: Залог с блокировкой по времени без нового контракта

Kaspa Deposit позволяет одной стороне заблокировать KAS в ончейн-ковенанте на фиксированный срок, в то время как другая сторона получает окно для предъявления претензии. Ключевой момент: он использует точно тот же контракт, что и Kaspa Escrow — десять путей расходования в основной сети Toccata — с одним отличием. Вместо написания нового кода Deposit просто меняет, кто какую роль играет.

Никакого нового контракта. Никакой новой поверхности для аудита. Просто инверсия ролей и двухфазный таймер.

Почему не писать новый контракт?

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

Практическая выгода — единая поверхность для аудита. Инвариант единственного входа, лимит на грифинг через комиссию, проверки сохранения значения — все проверки, отаудированные для эскроу, идентично применяются к Deposit, потому что байткод — буквально один и тот же файл. Обслуживание также общее: исправление в ковенанте или WASM-сборщике приносит пользу каждому шаблону сделки, работающему на его основе.

Инверсия ролей: тот же ковенант, другая семантика

Контракт escrow.sil определяет три слота для публичных ключей: buyer, seller и arbiter. Каждый путь расходования направляет средства buyer, seller или делит их между ними, с вычетом комиссии на фиксированный адрес feeSpk. Всего существует десять путей — полная карта описана в Путях расходования эскроу-ковенанта Kaspa.

Отображение при создании сделки выглядит так:

EscrowParams {
  buyer:  holder_pubkey,     // публичный «держатель» → buyer контракта
  seller: depositor_pubkey,  // публичный «вкладчик» → seller контракта
  arbiter: arbiter_pubkey,
  timeoutTo: 1,              // тайм-аут → seller → вкладчик
  ...
}

Установка timeoutTo = 1 (seller) гарантирует, что при истечении срока арбитра средства поступят вкладчику — стороне, предоставившей залог — а не стороне, которая его запрашивает.

Вот как меняется значение каждого пути при инверсии:

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

Две фазы: Срок и Окно претензий

Депозит имеет два последовательных временных интервала, оба измеряются в DAA-оценках — ончейн-часах сложности Kaspa, которые считают синие и объединенные красные блоки (Вики Kaspa):

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

Окно претензий — предустановленная продолжительность, выбираемая из белого списка значений (24, 48, 72, 96, 120 или 168 часов, выраженных в DAA-оценках). Это окно, в котором держатель может открыть претензию, отправив транзакцию dispute, подписанную ключом держателя. Если держатель открывает претензию, сделка переходит в режим DISPUTED — идентичный эскроу — и начинается отсчет срока арбитра.

Если окно претензий истекает без предъявления претензии, наблюдатель транслирует autoRelease, и средства вкладчика возвращаются к нему. Общее время до этого момента — сумма срока и окна претензий.

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

Урегулирование без подписей: когда никто не действует

Самое важное архитектурное свойство Deposit — то же самое, что делает Kaspa Safe устойчивым: определенные пути расходования не требуют вообще никакой подписи.

autoRelease() требует только age >= disputeWindow и режим ACTIVE. timeoutToSeller() требует только age >= arbiterDeadline, режим DISPUTED и timeoutTo == 1. Ни один путь не проверяет какую-либо подпись. Любой — вкладчик, держатель, наблюдатель, посторонний — может собрать и транслировать транзакцию. Средства поступят именно туда, куда предписывает ковенант.

На практике оффчейн-наблюдатель опрашивает активные сделки каждые 10 секунд, проверяя состояние UTXO и прогрессирование DAA-оценки. Когда таймер истекает, он автоматически транслирует транзакцию урегулирования. Вкладчик получает оповещение (Telegram, электронная почта или веб-уведомление, если подписан), но ему не нужно ничего подписывать или даже быть онлайн.

Именно это делает Deposit некастодиальным на практике, а не только в теории. Если сервис Kaspa Forge навсегда выйдет из строя, вкладчик может восстановить средства, взяв необработанные параметры ковенанта, локально собрав транзакцию autoRelease или timeoutToSeller и отправив ее в любой узел Kaspa. Инструмент командной строки с открытым исходным кодом escrowctl поддерживает это — тот же оффлайн-путь, который обслуживает эскроу-сделки, работает для депозитов без изменений.

Как Kaspa Forge реализует Deposit

Deposit не вводит новый бинарный файл контракта или отдельный WASM-модуль. Депозит — это запись в общей базе данных deals с полем template = "deposit". Это единственное поле сообщает пользовательскому интерфейсу, какие ярлыки показывать (вкладчик / держатель вместо покупатель / продавец) и какую временную семантику применять (срок + окно претензий вместо одного окна спора).

Точка входа — выделенный API-модуль, который принимает публичные ярлыки «вкладчик» и «держатель» и отображает их на параметры контракта seller и buyer при создании. После создания сделка проходит через ту же инфраструктуру, что и любое другое соглашение на платформе — общий реестр сделок, E2E чат-протокол (сообщения шифруются в браузере, закрепляются как ончейн-транзакции), конвейер споров, AI-медиатор для необязательных рекомендаций и человеческий арбитр для обязательных решений.

На фронтенде Desk показывает Deposit на отдельной вкладке с терминологией, специфичной для депозитов. React-маршруты живут в выделенном модуле функций, но используют то же WASM-ядро (vault-core-v5) и тот же зашифрованный профиль Desk. Приватные ключи выводятся из HD мастер-сид-фразы с использованием той же схемы разделения доменов HMAC-SHA512, которая питает Safe, Escrow и Marketplace — одна сид-фраза, несколько инструментов, ключи никогда не покидают браузер.

Структура комиссий унаследована напрямую от эскроу: 0,5% (минимум 1,2 KAS) при разрешении спора, 2% (минимум 5 KAS) при открытии спора. Параметр feeBudget — предельный лимит на сетевые комиссии на уровне ковенанта, ограниченный между 0,01 и 0,1 KAS — устанавливается при создании и соблюдается ончейн. Путь по тайм-ауту не облагается сервисной комиссией. Минимальный размер сделки — 50 KAS; верхнего лимита нет.

Унаследованная безопасность, общие ограничения

Повторно используя эскроу-ковенант, Deposit наследует все свойства безопасности, которые были отаудированы для этого контракта:

• Инвариант единственного входа. Каждый путь расходования начинается с require(tx.inputs.length == 1), закрывая вектор утечки через несколько UTXO, когда два UTXO с общим P2SH-адресом могут слить значение меньшего в комиссии.
• Лимит на грифинг через комиссию. require(feeBudget > 0 && feeBudget <= MAX_FEE_BUDGET) на всех путях, кроме migrate (который требует обеих подписи, поэтому владелец контролирует комиссии напрямую). Это предотвращает сжигание депозита наблюдателем или любой третьей стороной в завышенной сетевой комиссии на путях без подписей.
• Сохранение значения. Ограниченные пути проверяют первый выход и его нижний лимит по значению, гарантируя, что сумма депозита не может быть слита.

Известное ограничение ковенанта v3 также применяется: ограниченные пути проверяют outputs[0] и его значение, но не контролируют outputs.length. Официальные сборщики всегда создают канонические транзакции с одним выходом, а лимит feeBudget (0,01–0,1 KAS) ограничивает любую потенциальную утечку в гипотетическом втором выходе. Это задокументированный компромисс; строгая проверка на точное количество выходов запланирована для будущей версии ковенанта.

И как у эскроу, разрешение обязательных споров в Deposit зависит от человеческого арбитра. AI-медиатор предоставляет необязательную рекомендацию на основе стенограмм чатов и доказательств, но подпись arbitrateTo* исходит от человека, владеющего оффлайн-ключом. Если этот человек становится недоступен, путь по тайм-ауту в ковенанте — без подписи, без комиссии, средства вкладчику — является страховочной сетью. Вкладчик всегда защищен временем.

---