Kaspa Escrow — комиссии: как ковенанты обеспечивают оплату сервиса на уровне блокчейна

Когда вы пользуетесь традиционным эскроу — будь то банк, платформа или телеграм-«гарант», — комиссия равна тому, что назначит посредник. Он хранит средства, устанавливает условия, и вы доверяете ему взять ровно столько, сколько справедливо. Kaspa Escrow снимает эту необходимость в доверии. Структура комиссий — это не нормативный документ, а код, вшитый в on-chain ковенант, на котором хранятся ваши средства. Сумма, адрес получателя и условия, при которых списываются комиссии, фиксируются ещё до того, как на счёт поступит первый сомпи.

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

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

В кастодиальном эскроу обеспечение комиссий тривиально: посредник держит деньги и вычитает свою долю перед выдачей. В некастодиальном эскроу средства находятся в ковенанте, который ни одна из сторон, ни сервис не могут изменить в одностороннем порядке. Задача: как гарантировать оплату сервису, если сервис никогда не хранит средства?

Ответ Kaspa — интроспекция выходов. Скрипт ковенанта проверяет не только *кто* подписывает — он проверяет *куда идут деньги*. Каждый путь расходования анализирует выходы транзакции и требует определённый выход на адрес комиссии с суммой, соответствующей уровню комиссии. Если выход отсутствует, неверен или недофинансирован, транзакция недействительна. Майнеры не включат её в блок, ноды не станут её ретранслировать.

Ковенант: 10 путей, три режима комиссий

Контракт escrow.sil определяет 10 путей расходования, организованных вокруг двух ролей (buyer, seller), публичного ключа арбитра, окна спора и дедлайна арбитра. Состояние контракта — единственное поле mode: 0 = ACTIVE, 1 = DISPUTED.

Не каждый путь взимает комиссию. Ковенант определяет три различных режима:

Комиссия за разрешение (feeResolve)

Применяется к четырём путям «обычного разрешения»:

• release(buyerSig) — покупатель подтверждает получение → продавец получает оплату
• refund(sellerSig) — продавец возвращает средства → покупателю возмещается сумма
• mutual(buyerSig + sellerSig) — обе стороны соглашаются закрыть сделку (разделение, частичный возврат, любая договорённость)
• autoRelease() — подпись не требуется; окно спора истекло без спора → продавец получает оплату

В продакшене feeResolve рассчитывается как:

max(0.5% of deal value, 1.2 KAS minimum)

Сделка на 500 KAS заплатит 2,5 KAS комиссии. Сделка на 50 KAS (минимум Kaspa Escrow) заплатит 1,2 KAS — порог не допускает пылевых комиссий, расход на которые превышает их номинал.

Комиссия при споре (feeDispute)

Применяется, когда арбитр разрешает оспариваемую сделку:

• arbitrateToBuyer(arbSig) — арбитр выносит решение в пользу покупателя
• arbitrateToSeller(arbSig) — арбитр выносит решение в пользу продавца
• arbitrateSplit(arbSig) — арбитр разделяет средства между обеими сторонами

max(2% of deal value, 5 KAS minimum)

Повышенная ставка отражает дополнительную работу: AI-форензику, анализ зашифрованных переписок, исследование доказательств (верификация медиа, анализ кросс-чейн транзакций) и финальную подпись живого арбитра. Оспариваемая сделка на 500 KAS обойдётся в 10 KAS.

Без комиссии (тайм-аут)

• timeoutToBuyer() — дедлайн арбитра истёк, timeoutTo==0 → покупатель получает всё
• timeoutToSeller() — дедлайн арбитра истёк, timeoutTo==1 → продавец получает всё

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

Подробный разбор механики каждого пути — в описании путей расходования.

Как комиссии попадают в блокчейн: выход feeSpk

Каждый путь с комиссией формирует транзакцию с обязательной структурой выходов:

output[0] → feeSpk (service fee address, 36-byte script pubkey)
output[1] → recipient (buyer, seller, or split)

Ковенант проверяет, что outputs[0] платит правильному feeSpk на правильную сумму. feeSpk — это параметр конструктора, задаваемый при компиляции экземпляра контракта эскроу из escrow.sil. Оператор сервиса его предоставляет, но ковенант фиксирует его при создании сделки.

Вот механизм обеспечения. Ковенант не запрашивает комиссию — он требует выход с комиссией на правильный адрес и на минимальную сумму, иначе транзакция недействительна.

Для arbitrateSplit структура выходов становится трёхэлементной: комиссия, доля покупателя, доля продавца. Каждая доля должна удовлетворять порогу MIN_OUT в 1 KAS, чтобы избежать пылевых выходов.

Антиобходной инвариант: почему mutual не может пропустить комиссии

Вот тонкое место. Путь mutual требует подписи и покупателя, и продавца. Имея оба ключа, стороны обладают полным контролем над транзакцией — теоретически они могли бы отправить все средства одной стороне без выхода с комиссией.

Ковенант это предотвращает. Путь mutual обеспечивает то, что мы называем инвариантом K1: выход с комиссией обязателен, даже если обе стороны предпочли бы обойтись без него.

// inside the mutual path:
require(outputs[0].value >= feeResolve)
require(outputs[0].script_pubkey == feeSpk)

Без инварианта K1 покупатель и продавец могли бы обходить комиссии, маршрутизируя через mutual вместо release или refund. Инвариант закрывает эту лазейку на уровне протокола. Обе стороны по-прежнему могут перенаправлять средства друг другу — делить, частично возвращать, как угодно — но выход с комиссией не обсуждается.

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

Бюджет комиссий: ограничение сетевых комиссий на безключевых путях

Комиссии сервиса и сетевые (майнерские) комиссии — это разные вещи. Ковенант контролирует комиссии сервиса через выход feeSpk. Сетевые комиссии контролируются отдельным механизмом: параметром конструктора feeBudget.

feeBudget — 11-й параметр escrow.sil. Он ограничивает максимальную сетевую комиссию, которую может потребить любой безключевой путь расходования:

require(feeBudget > 0 && feeBudget <= MAX_FEE_BUDGET)
// MAX_FEE_BUDGET = 10,000,000 sompi (0.1 KAS)

Атака, которую он предотвращает

Безключевые пути — autoRelease и timeout* — могут быть транслированы кем угодно, а не только сторонами сделки. Off-chain вотчер транслирует их автоматически, но то же самое может сделать любая третья сторона, мониторящая блокчейн. Без ограничения комиссий злоумышленный наблюдатель мог бы создать безключевую транзакцию, удовлетворяющую требованиям ковенанта к выходам, но сжигающую бо́льшую часть стоимости сделки в виде завышенной майнерской комиссии — извлекая выгоду как майнер или через пуловые договорённости.

С ограничением feeBudget даже худшая безключевая транзакция потребляет не более 0,1 KAS сетевых комиссий. Для сделки на 500 KAS это 0,02%.

Продакшен-ограничения

Off-chain билдеры Kaspa Forge применяют более узкий диапазон через привязочный слой:

feeBudget ∈ [0.01 KAS, 0.1 KAS]

Нижняя граница предотвращает сделки с настолько малым бюджетом, что безключевые пути становятся экономически невозможными — одна только комиссия за ретрансляцию может превысить бюджет, сделав транзакцию неретранслируемой. On-chain нижняя граница — только > 0; продакшен-порог обеспечивается off-chain.

Исключение: migrate

Путь migrate, требующий подписей обоих ключей — горячего и тревожного, — единственный вход, который НЕ обеспечивает ограничение feeBudget. Это намеренно: с обеими подписями владелец обладает односторонним контролем над транзакцией. Ограничение комиссии добавило бы сложности без выигрыша в безопасности.

На всей платформе Kaspa Forge (7 путей хранилища + 10 путей эскроу = 17 входов) ограничение feeBudget применяется к 16. Единственное исключение — путь migrate в Kaspa Safe, который требует оба ключа, а значит — полного согласия владельца.

Известное ограничение v3

Текущая версия ковенанта (v3) имеет задокументированное ограничение: она проверяет, что outputs[0] имеет правильную сумму и script pubkey, но не контролирует tx.outputs.length. Автор транзакции теоретически мог бы добавить дополнительные выходы в рамках окна feeBudget — направив средства, которые обычно идут на сетевую комиссию, на другие адреса.

Это не ставит под угрозу тело эскроу. Инвариант сохранения стоимости (out[0] + out[1] >= in - feeBudget) гарантирует, что средства сделки нельзя вывести. Но граница сетевой комиссии имеет теоретическую лазейку через дополнительные выходы. Практическое влияние минимально, поскольку билдеры Kaspa Forge всегда создают канонические транзакции с минимальным числом выходов, а сам feeBudget невелик (максимум 0,1 KAS). Это ограничение — известный пункт для цикла обновлений v4 в паре с внешним аудитом.

Как Kaspa Forge использует это в продакшене

Архитектура комиссий охватывает несколько компонентов сервиса Kaspa Escrow:

Создание сделки (deals.rs): функция fees_for() рассчитывает точные суммы feeResolve и feeDispute на основе стоимости сделки. Обе хранятся рядом с параметрами ковенанта и видны обеим сторонам до финансирования. Минимальная стоимость сделки — 50 KAS: ниже этого порога комиссия при споре (минимум 5 KAS) поглотила бы более 10% сделки.

WASM-билдеры (escrow_core.rs): браузерные билдеры транзакций встраивают выход с комиссией как outputs[0] в каждый путь с комиссией. feeBudget — параметр конструктора, встроенный в P2SH-адрес: он не может измениться без переразвёртывания контракта на новый адрес.

Вотчер (watcher.rs): off-chain вотчер управляет безключевыми путями — autoRelease после окна спора, timeout* после дедлайна арбитра. Каждая транслируемая транзакция включает правильный выход с комиссией в рамках ограничения feeBudget. Вотчер также отправляет предупреждения на 50% и 90% окна спора, чтобы держать обе стороны в курсе.

Процесс спора (dispute_api.rs): когда арбитр подписывает вердикт, комиссия пути арбитража — feeDispute, то есть повышенный уровень. Ковенант это обеспечивает; арбитр не может её отменить.

Адрес получателя комиссий един для всех инструментов ковенантов Kaspa Forge — Kaspa Safe, Escrow, Deposit и Marketplace — обеспечивая единый и прозрачный сбор комиссий.

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

Предсказуемость vs. гибкость. Фиксированные уровни комиссий (0,5% / 2%) прозрачны и аудируемы on-chain, но они не могут адаптироваться к рыночным условиям без развёртывания новой версии контракта. Это преимущество для доверия — вы знаете комиссию до финансирования — но ограничение для ценовой гибкости.

Инвариант K1 ограничивает гибкость mutual. Обе стороны должны принять, что взаимное закрытие всегда включает комиссию, даже если они договорились разделить средства без участия сервиса. Пользователи, ожидающие полного двустороннего контроля при двух подписях, могут быть удивлены. Альтернатива — добровольные комиссии — подорвала бы всю модель.

Зазор в длине выходов v3. Обеспечение комиссий надёжно, но не абсолютно герметично. Тело эскроу в безопасности, но граница комиссий имеет теоретическую лазейку через дополнительные выходы. Практическое влияние минимально благодаря каноническому поведению билдеров и малому лимиту feeBudget, но об этом стоит знать.

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

Минимальный порог сделки. Минимум в 50 KAS существует потому, что ниже него комиссия при споре (минимум 5 KAS) поглотила бы более 10% стоимости сделки. Вы можете создавать сделки и меньшего размера on-chain — ковенант не устанавливает минимум — но экономика не работает для разрешения споров.