Как контракт эскроу Kaspa делает exit-мошенничество невозможным

Когда вы отправляете KAS Telegram-«гаранту» для P2P-сделки, вы доверяете обещанию незнакомца. Этот незнакомец может исчезнуть с вашими деньгами в любой момент — и блокчейн ничего не сможет с этим сделать, потому что деньги уже в его кошельке.

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

Что такое ковенант Kaspa?

Хардфорк Toccata в Kaspa представил ковенанты в мейннете. Ковенант — это скрипт (написанный на Silverscript), который ограничивает способ расходования конкретной монеты. Думайте о нем как о программируемом замке: монета переместится только тогда, когда транзакция удовлетворит каждое требуемое скриптом условие — правильные подписи, правильные направления, правильный тайминг.

blockDAG Kaspa обеспечивает встроенные часы: оценка DAA — счетчик, скорректированный по сложности, который увеличивается при каждом слиянии блока. Скрипты ковенантов используют оценки DAA для временно заблокированных путей, а не метки реального времени, что делает тайминг детерминированным с точки зрения цепи. Тот же паттерн ковенанта лежит в основе Kaspa Safe, нашего хранилищного инструмента — если вы читали, как работает хранилище, модель переносится напрямую.

Контракт: Параметры и состояние

Контракт escrow.sil принимает фиксированный набор параметров при создании:

# escrow.sil — параметры конструктора
buyer, seller, arbiter   # три публичных ключа
disputeWindow            # Оценки DAA: «период возврата»
arbiterDeadline          # Оценки DAA: время для действий арбитра
timeoutTo                # 0 = покупатель, 1 = продавец (резервный)
feeSpk                   # 36-байтовый скрипт публичного ключа для сервисной комиссии
feeResolve, feeDispute   # суммы сервисной комиссии (сомпи)
feeBudget                # максимальная сетевая комиссия, лимит 0.1 KAS
initMode                 # начальный режим (0 = АКТИВНЫЙ)

Контракт хранит одну изменяемую переменную состояния: mode, которая равна либо 0 (АКТИВНЫЙ), либо 1 (СПОРНЫЙ). Когда сделка финансируется, UTXO начинает существование в АКТИВНОМ режиме. Режим определяет, какие пути расходования доступны — и когда вы увидите все десять, замысел станет ясен.

Жизненный цикл сделки: Десять путей

Проследим сделку от финансирования до разрешения. Каждый этап показывает, какие пути открываются.

Финансирование → АКТИВНЫЙ

Сторона отправляет KAS на адрес эскроу. UTXO появляется в АКТИВНОМ режиме. С этого момента контракт может быть потрачен через любой из нижеперечисленных путей, соответствующих текущему режиму.

Кооперативное закрытие (любой режим — АКТИВНЫЙ или СПОРНЫЙ)

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

• release(buyerSig) — Покупатель подтверждает удовлетворение. Весь баланс, за вычетом комиссии за разрешение, идет продавцу. Это счастливый конец.
• refund(sellerSig) — Продавец признает невозможность доставки. Весь баланс, за вычетом комиссии за разрешение, идет покупателю. Изящный отход.
• mutual(buyerSig + sellerSig) — Обе стороны согласны. Они могут разделить средства между покупателем и продавцом в любой пропорции, но вывод сервисной комиссии обязателен. (Это правило антиобхода K1: даже если обе стороны сговорятся пропустить комиссию, ковенант отклонит транзакцию.)

Кооперативные пути всегда работают. Спор не блокирует стороны в режиме противостояния — они могут урегулировать напрямую в любой момент.

Окно спора (только АКТИВНЫЙ)

Пока UTXO находится в АКТИВНОМ режиме, у покупателя есть окно, измеряемое в оценках DAA, чтобы поднять спор. Может произойти два варианта:

• Окно истекает без спора → срабатывает autoRelease(). Этот путь не требует подписи — любой может его транслировать. Продавец получает оплату, за вычетом комиссии за разрешение. Это оптимистичный сценарий по умолчанию: поставьте товар, и сделка закроется автоматически.
• Покупатель подписывает dispute(buyerSig) → Контракт переключается в СПОРНЫЙ. UTXO пересоздается (его «возраст» обнуляется), и начинается новый отсчет: arbiterDeadline. Средства не перемещаются — деньги все еще заблокированы в ковенанте, но правила изменились.

Арбитражное разрешение (только СПОРНЫЙ)

После того как спор становится активным, становится актуальным ключ подписи арбитра. Открываются три пути:

• arbitrateToBuyer(arbSig) — Полный возврат покупателю, за вычетом комиссии за спор.
• arbitrateToSeller(arbSig) — Полная оплата продавцу, за вычетом комиссии за спор.
• arbitrateSplit(arbSig) — Разделение между покупателем и продавцом. Оба вывода должны быть ≥ 1 KAS (защита от пыли KIP-9). Все три арбитражных пути взимают комиссию за спор, которая выше комиссии за разрешение.

Арбитр может выбирать между покупателем и продавцом. Четвертого варианта нет — контракт его не содержит.

Переключатель мертвеца (только СПОРНЫЙ)

Если arbiterDeadline истекает без арбитражного разрешения:

• timeoutToBuyer() — Срабатывает, когда timeoutTo == 0. Подпись не требуется. Сервисная комиссия не взимается. Покупатель получает полный баланс.
• timeoutToSeller() — Срабатывает, когда timeoutTo == 1. Те же условия. Продавец получает полный баланс.

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

Полный справочник

Все десять точек входа, одним взглядом:

• release(buyerSig) — покупатель → продавец · комиссия за разрешение
• refund(sellerSig) — продавец → покупатель · комиссия за разрешение
• mutual(buyerSig + sellerSig) — произвольное разделение · комиссия за разрешение (обязательна)
• dispute(buyerSig) — АКТИВНЫЙ → СПОРНЫЙ · возраст сбрасывается
• autoRelease() — без подписи · возраст ≥ окно → продавец · комиссия за разрешение
• arbitrateToBuyer(arbSig) — арбитр → покупатель · комиссия за спор
• arbitrateToSeller(arbSig) — арбитр → продавец · комиссия за спор
• arbitrateSplit(arbSig) — арбитр → покупатель + продавец, каждый ≥ 1 KAS · комиссия за спор
• timeoutToBuyer() — без подписи · возраст ≥ дедлайн, timeoutTo=0 → покупатель · без комиссии
• timeoutToSeller() — без подписи · возраст ≥ дедлайн, timeoutTo=1 → продавец · без комиссии

Инвариант, убивающий exit-мошенничество

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

Три дополнительных защитных механизма усиливают это:

Инвариант одного входа. Каждый путь начинается с требования tx.inputs.length == 1. Это предотвращает объединение в одной транзакции нескольких UTXO, которое могло бы связать монету эскроу с другими монетами и направить разницу в качестве комиссии майнерам. UTXO эскроу должен быть потрачен отдельно.

# Каждый путь обеспечивает:
require(tx.inputs.length == 1)

# Каждый скрипт вывода должен быть одним из:
require(out.scriptPublicKey == buyer_spk  ||
        out.scriptPublicKey == seller_spk ||
        out.scriptPublicKey == feeSpk)

Лимит бюджета комиссии. Сетевая комиссия (то, что идет майнерам) ограничена значением feeBudget, которое само не может превышать 10 000 000 сомпи — 0.1 KAS. Это останавливает атакующего, ошибочный монитор или скомпрометированный ретранслятор от сжигания баланса эскроу в комиссиях за транзакции.

Сохранение стоимости на арбитражных путях. Арбитражные пути явно обеспечивают out[0] + out[1] >= in - feeBudget. Стоимость не «утекает» между выводами.

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

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

В Kaspa Forge escrow.sil компилируется в наше WASM-ядро (kaspa-safe-core) через include_str!. Код на стороне браузера и бэкенд используют абсолютно одинаковый исходный контракта — никакого вторичного преобразования, которое могло бы рассинхронизироваться.

Жизненный цикл сделки на нашем бэкенде (kaspa-safe-server) отражает конечный автомат:

1. Создание — инициирующая сторона выбирает роль, тип сделки, сумму и окно спора (из предустановок: 24/48/72/96/120/168 калиброванных по DAA часов). Сервер генерирует одноразовый код присоединения (TTL 72 часа). 2. Присоединение — вторая сторона вводит код. Сервер вычисляет адрес эскроу на основе обоих публичных ключей и всех параметров конструктора. Адрес детерминирован — любая из сторон может проверить его независимо. 3. Финансирование — KAS поступает на адрес эскроу. Цикл мониторинга (10-секундный интервал) обнаруживает UTXO и переводит сделку в статус финансирована. 4. Чат — каждая сторона получает отдельный ключ чата (отличный от ключа эскроу — раскрытие ключа чата в споре не ставит под угрозу средства). Сообщения зашифрованы сквозным шифрованием с использованием ECIES (k256 ECDH + ChaCha20-Poly1305) и привязаны к BlockDAG в виде блокчейн-транзакций. Сервер передает только шифротекст. 5. Закрытие или спор — подписи создаются локально в браузере через профиль Kaspa Forge на рабочем столе; ключи никогда не покидают устройство. Подписанная транзакция транслируется. 6. Медиация ИИ — если покупатель инициирует спор, обе стороны могут раскрыть свои ключи чата ИИ-медиатору (в настоящее время Xiaomi MiMo v2.5 Pro через OpenRouter). Медиатор восстанавливает разговор, проводит криминалистический анализ прикрепленных доказательств (EXIF изображений, трек-номера, идентификаторы криптотранзакций) и выносит необязывающий вердикт. Любая сторона может принять его или передать дело человеческому арбитру. 7. Человеческий арбитраж — арбитр подписывает с помощью офлайн-ключа. Приватный ключ никогда не хранится на сервере; сконфигурирован только публичный ключ. Ковенант обеспечивает, что даже подпись арбитра может направить средства только покупателю или продавцу. 8. Тайм-аут — если ни одна сторона не действует и дедлайн арбитра истекает, монитор автоматически транслирует транзакцию тайм-аута. Ключи не требуются.

Восстановление без сервиса. Если Kaspa Forge полностью отключится, покупатель и продавец по-прежнему смогут выполнить кооперативные пути (освобождение, возврат, взаимное) с помощью любого кошелька Kaspa, поддерживающего ковенанты Toccata. Путь тайм-аута транслируется вообще без подписей. Единственный путь, требующий инфраструктуры платформы, — это путь спора-арбитража, и даже там резервным вариантом является тайм-аут — средства не застрянут.

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

Честный учет того, что этот дизайн не решает, и где он ограничивает пользователей:

• Бета-лимиты. Текущие ограничения — 50–10 000 KAS на сделку. Ниже 50 KAS порог комиссии за спор (минимум 5 KAS) будет потреблять более 10% от эскроу. Выше 10 000 KAS мы хотим больше опыта в мейннете, прежде чем повышать потолок.

• Зависимость от арбитра. Если ключ арбитра утерян, спорные сделки могут быть разрешены только через путь тайм-аута. Направление тайм-аута фиксируется при создании — вы не можете передумать, кто получит резервные средства, после факта. Это сознательный компромисс: восстанавливаемый ключ арбитра создал бы другую поверхность атаки.

• Оценка DAA, а не реальное время. Окна споров и дедлайны арбитров измеряются в оценках DAA, а не в минутах или часах. При текущей скорости блоков Kaspa предустановки приблизительно соответствуют реальным интервалам (например, 72 часа), но точное соотношение зависит от хешрейта и сетевых условий. Мы представляем предустановки в человекочитаемых часах, калиброванных под текущий темп DAA.

• Необязывающий вердикт ИИ. Мнение ИИ-медиатора носит рекомендательный характер — контракт не может его обеспечить. Оно помогает сторонам прийти к информированному взаимному соглашению, но только реальная подпись (от стороны или арбитра) может переместить средства. Это функция, а не ошибка: мы не хотим LLM с полномочиями на расходование.

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

• Защита от пыли. Минимальный вывод в 1 KAS на арбитражных путях разделения (из KIP-9) означает, что арбитр не может создать микровыводы. Это сетевое ограничение, которое защищает от накопления пыли в наборе UTXO.