Как использовать Kaspa Escrow для P2P-сделки

Вы хотите продать KAS за фиат или купить цифровой товар за KAS у кого-то, кого никогда не встречали. Telegram-эскроу «гарант» решает это — пока вы не осознаете, что гарант хранит ваши деньги в своем личном кошельке и взимает 3–10% за эту «привилегию». Kaspa Escrow — это альтернатива: некастодиальный ончейн-контракт, где средства заблокированы в ковенанте Toccata, а не в горячем кошельке человека. Этот гайд проведет через полные механики — от создания сделки через финансирование, чат, выпуск, возврат и спор — чтобы вы точно понимали, что контракт позволяет, а что нет.

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

Любая P2P-торговля имеет разрыв во времени. Покупатель отправляет KAS первым — и продавец может исчезнуть. Продавец отправляет первым — и покупатель может заявить, что ничего не получил. Традиционное эскроу решает это, вводя посредника, который удерживает средства — но посредник становится новым риском.

Kaspa Escrow лишает посредника возможности красть. Средства находятся в ковенанте Toccata — ончейн-скрипте, который точно определяет, кто может потратить выход и при каких условиях. Оператор управляет веб-сайтом, чат-ретранслятором и (при необходимости) арбитром, но деньги никогда не касаются кошелька оператора. Математика заменяет обещания.

Ковенант: десять путей, никакого воровства

Контракт эскроу (escrow.sil) компилируется в адрес Kaspa при создании сделки. Он содержит три публичных ключа — buyer, seller, arbiter — и несколько временных параметров в единицах DAA-счёта. Как только средства поступают на этот адрес, только десять путей могут их переместить:

Ключевой инвариант: каждый путь отправляет средства только покупателю, продавцу или на фиксированный адрес комиссии. Арбитр не может перенаправить деньги себе или третьей стороне — скрипт просто не содержит такого пути. Каждый путь также обеспечивает require(tx.inputs.length == 1), предотвращая атаки с использованием нескольких UTXO.

Параметр feeBudget (ограниченный 0.1 KAS) ограничивает выход комиссии так, чтобы «излишек» нельзя было тайно вывести. Путь mutual — единственное кооперативное закрытие, которое *требует* выхода комиссии — без этого две честные стороны могли бы полностью обойти сервисную комиссию.

Пошагово: жизненный цикл сделки

1. Создание

Одна из сторон открывает kaspaforge.org/escrow.html и выбирает:

• Роль — покупатель или продавец
• Шаблон — товары, внебиржевой обмен или услуги
• Сумму — в KAS (минимум 50 KAS, верхнего предела нет)
• Условия — свободный текст, описывающий сделку
• Окно спора — один из шести предустановленных вариантов: 24 ч / 48 ч / 72 ч / 96 ч / 120 ч / 168 ч. Каждый вариант автоматически устанавливает дедлайн для арбитра (например, окно 72 ч → дедлайн арбитра 168 ч). Интерфейс предлагает вариант по умолчанию, соответствующий шаблону (товары → 72 ч, OTC → 24 ч, услуги → 120 ч). Пользовательские значения вне предустановок невозможны — это предотвращает «микро-окно», которое лишило бы другую сторону реальной возможности оспорить.

Браузер генерирует три пары ключей локально:

• Ключ сделки — подписывает ончейн-транзакции расходования
• Ключ финансирования (только для покупателя) — управляет адресом предоплаты
• Ключ чата — шифрует сквозные сообщения сделки (отдельный от ключа сделки; не может перемещать средства)

Все три записываются в список восстановления (текстовый файл) и никогда не покидают браузер. Сервер получает только публичные ключи. Создатель получает ссылку-приглашение и закладку deal.html?id=<N>.

2. Присоединение

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

3. Финансирование

Покупатель видит адрес финансирования — свой *собственный* адрес, выведенный из его ключа финансирования — и QR-код. Он отправляет KAS на этот адрес из любого кошелька Kaspa. Затем он нажимает «Заблокировать в эскроу». Браузер собирает транзакцию, которая перемещает средства с адреса финансирования в ончейн-ковенант (адрес эскроу). Обычный перевод на адрес эскроу *не* создает контракт — двухэтапный процесс (пополните свой адрес, затем заблокируйте) гарантирует, что выход ковенанта имеет ровно правильный скрипт и параметры.

4. Активный период

После финансирования обе стороны видят панель «активно». Таймер окна спора обратного отсчета. В течение этого окна:

• Покупатель может нажать «Выпуск» → средства идут продавцу (за вычетом комиссии за выпуск).
• Продавец может нажать «Возврат» → средства возвращаются покупателю (за вычетом комиссии за выпуск).
• Обе стороны могут использовать чат сделки — сквозные зашифрованные сообщения, привязанные к ончейну через протокол Kasia. Сервер ретранслирует шифротекст; он никогда не видит открытый текст. Медиа (изображения, видео) шифруются на стороне клиента случайным ключом, загружаются как непрозрачный блоб, а ключ расшифровки передается внутри зашифрованного сообщения чата. После расшифровки клиент проверяет хэш SHA-256 по привязке в сообщении.

5. Автоматический выпуск (удачный путь при молчании)

Если ни одна из сторон ничего не нажимает и окно спора истекает, цикл наблюдения сервера отправляет транзакцию autoRelease. Средства идут продавцу. Это защищает продавцов от покупателей, которые получают товар, а затем исчезают.

6. Спор

Если покупатель нажимает «Открыть спор» в течение окна, ковенант переходит из состояния ACTIVE (режим 0) в DISPUTED (режим 1). UTXO пересоздается в ончейне с новым счетчиком возраста, и запускается таймер arbiterDeadline. С этого момента:

• Обе стороны предоставляют материалы арбитру через панель сделки (описания, скриншоты, номера отслеживания).
• Любая из сторон может раскрыть свой секретный ключ чата арбитру, который затем расшифровывает транскрипцию разговора в качестве доказательства. Ключ чата отделен от ключа сделки — его раскрытие не дает арбитру контроля над средствами.
• Арбитр выносит вердикт: всё покупателю, всё продавцу или раздел на N%. Вердикт не является обязательным — любая из сторон может его отклонить. Если ни одна из сторон не принимает решение в течение 24 часов (настраивается через KSAFE_VERDICT_WINDOW_SECS), дело автоматически эскалируется.
• Если арбитр молчит до истечения дедлайна, срабатывает экстренный тайм-аут: средства идут стороне по умолчанию (обычно покупателю) вообще без сервисной комиссии.

На любом этапе спора покупатель по-прежнему может сделать «Выпуск», а продавец — «Возврат» — мирное урегулирование всегда доступно.

Управление ключами и восстановление

У каждой сделки свои ключи, сгенерированные в браузере. Список восстановления — единственная копия. Его потеря означает потерю доступа к вашей стороне сделки. Средства не исчезнут — они переместятся по обычному пути (выпуск, возврат, автоматический выпуск или тайм-аут) — но вы утратите возможность инициировать действия со своей стороны.

Опубликованный набор для восстановления (github.com/Kaspaforge/kaspaforge/tree/main/recovery-kit) содержит чистое ядро на Rust и инструмент командной строки (dealctl), который может извлекать, проверять, финансировать, выпускать, возвращать, оспаривать и собирать транзакции офлайн. Он подключается напрямую к любому узлу Kaspa v2+ через gRPC — никаких размещенных эндпоинтов не требуется. Существует поток подписания с воздушным зазором: офлайн-машина хранит ключ, онлайн-машина готовит транзакцию, а подписанный результат отправляется онлайн. Четыре раунда независимого обзора завершены, все находки закрыты.

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

Некастодиальность ≠ отсутствие доверия в арбитраже. Контракт гарантирует, что средства не могут быть украдены. Он не гарантирует справедливого вердикта. Справедливость исхода спора зависит от человеческого арбитра (или ИИ-посредника), оценивающего доказательства. Вердикт ИИ-арбитра явно не является обязательным.

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

Падение сервиса ≠ потеря средств. Путь экстренного тайм-аута работает без какого-либо сервера или подписи. Если Kaspa Forge исчезнет завтра, ваши средства вернутся стороне по умолчанию, когда истечет дедлайн арбитра. CLI-утилита восстановления также может принудительно рассчитать любое состояние сделки в любом узле Kaspa.

Внешний аудит ещё впереди. Контракт прошел стресс-тестирование (52/52 проверок VM, полный сквозной тест в simnet, четыре раунда независимого обзора набора восстановления), но формальный внешний аудит еще не завершен. Проверьте контракт в ончейне, прежде чем вкладывать значительные суммы.

Минимум 50 KAS. Ниже этого порога комиссия за арбитраж забирает слишком большую долю. Верхнего предела нет.

Принудительное взимание комиссий. Комиссия за выпуск/возврат (0,5%, минимум 1,2 KAS) и комиссия за спор (2%, минимум 5 KAS) обеспечены самим скриптом — они не являются необязательными и не могут быть обойдены. Комиссия показывается на панели перед вашим подтверждением.

Очистка конфиденциальных данных. При закрытии сделки сервер удаляет доказательства, материалы для расследования, взаимные подписи и данные оплаты покупателя. Только метод сделки и статус финальной проверки остаются в виде обезличенной статистики.

---

*Исходный код контракта (escrow.sil), ядро восстановления и CLI-инструмент опубликованы на github.com/Kaspaforge/kaspaforge. Общий обзор того, как Kaspa Forge строится на ковенантах Toccata, см. в архитектурном индексе.*