Kaspa Escrow Процедура спора: от раскрытия ключей чата до AI-вердикта

Когда два незнакомца торгуют через интернет, самое сложное — не сама транзакция, а то, что происходит, когда что-то идёт не так. Традиционные крипто-сервисы эскроу решают эту проблему, храня ваши средства в собственном кошельке и прося вас доверять тому, что они вынесут справедливое решение. Kaspa Escrow идёт другим путём: средства находятся в ковенанте в блокчейне, а слой разрешения споров — E2E-чат, движок AI-расследования и арбитр-человек — работает полностью вокруг этого контракта, не прикасаясь к ключам.

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

Основа в блокчейне

Прежде чем разбирать внесетевой процесс, полезно понять, что обеспечивает контракт. Контракт Kaspa Escrow (escrow.sil) определяет десять путей расходования. К спорам относятся следующие:

• dispute(buyerSig) — переводит UTXO из состояния ACTIVE в DISPUTED, сбрасывает его возраст и запускает таймер дедлайна арбитра.
• arbitrateToBuyer(arbSig), arbitrateToSeller(arbSig), arbitrateSplit(arbSig) — три пути, которые может подписать арбитр-человек; каждый выплачивает только покупателю, продавцу или обоим (каждый выход разделения — не менее 1 KAS).
• timeoutToBuyer() / timeoutToSeller() — пути без ключей, которые активируются по истечении дедлайна арбитра, гарантируя, что средства выйдут из контракта, даже если все внесетевые участники исчезнут.

Критический инвариант: ни один путь в контракте не может выплатить никому, кроме {buyer, seller, feeSpk}. Арбитр физически не способен перенаправить средства куда-либо ещё. Это не обещание — это скрипт, исполняемый каждым узлом Kaspa.

Пять этапов спора

Этап 1 — Заявления

Когда покупатель открывает спор, обе стороны подают структурированное заявление: refund, release или split (с предложенной пропорцией). Каждое заявление аутентифицируется токеном сделки стороны. Сервер фиксирует заявление, но UTXO в блокчейне пока не меняется. Транзакция dispute покупателя переводит ковенант в режим DISPUTED, сбрасывая возраст UTXO и запуская дедлайн арбитра.

Пресеты окон задаются на стороне сервера в белом списке: для сделок с товарами по умолчанию 72 часа на спор / 168 часов на арбитра; для OTC-сделок — 24/72; для услуг — 120/240. Ни одна сторона не может расширить окно после финансирования. Отсчёт времени использует DAA-скор — подробнее о том, как DAA-скор управляет временными окнами, можно прочитать в базе знаний Kaspa.

Этап 2 — Раскрытие ключей чата

Это граница приватности. На протяжении всей сделки обе стороны общаются по протоколу Kasia — каждое сообщение зашифровано методом ECIES (ECDH на secp256k1 + ChaCha20-Poly1305) и закреплено в BlockDAG в виде транзакции. Сервер передаёт шифротекст; он никогда не видит открытый текст.

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

Обычная сделка:  Сторона A ──[ECIES шифротекст]──▶ Сервер ──▶ Сторона B
                 Сервер ничего не видит.

Спор подан:      Сторона A раскрывает chat_sk ──▶ Сервер расшифровывает переписку
                 Сторона B раскрывает chat_sk ──▶ Сервер расшифровывает переписку
                 AI-медиатор читает открытый текст, выносит вердикт.

Медиа-вложения следуют тому же принципу: каждый файл зашифрован отдельным ключом, загружен как blob и описан внутри E2E-сообщения. Медиатор сверяет хеши SHA-256 с закреплениями в блокчейне для обнаружения подделки. Приватный ключ чата хранится только в оперативной памяти сервера — он никогда не сохраняется на диск или в базу данных.

Этап 3 — AI-расследование и вердикт

После расшифровки чата в работу последовательно включаются две автоматизированные системы.

Медиа-расследование (media_probe.rs) проверяет каждое вложение:

• Проверка целостности: хеш SHA-256 против закрепления в блокчейне, проверка magic-байтов, извлечение EXIF-данных для изображений.
• Изображения: передаются в модель компьютерного зрения для классификации содержимого.
• Видео: извлечение ключевых кадров и аудиодорожки через ffmpeg/ffprobe.
• Документы: PDF парсятся через poppler.
• Отслеживание товаров: проверка трек-номеров S10, запрос к SOAP API Почты России.
• OTC-верификация: для сделок с поддерживаемой встречной стороной (USDT на Tron/TON/ETH/BSC, USDC на нескольких EVM-цепочках, BTC, LTC) система запрашивает обозреватели блокчейнов для подтверждения заявленного ID транзакции. Это носит лишь рекомендательный характер — значок статуса, видимый обеим сторонам, а не условие, обеспечиваемое контрактом.

Временные файлы при расследовании хранятся только в оперативной памяти (/dev/shm), никогда не сохраняются на диск.

Отчёт расследования структурируется в промпт для AI-медиатора (arbiter.rs). Поведенческие инструкции медиатора встроены в бинарный файл на этапе компиляции. Он вызывает OpenAI-совместимый эндпоинт (в продакшене: xiaomi/mimo-v2.5-pro через OpenRouter, temperature 0, строгий JSON-вывод) с полной расшифровкой переписки, доказательствами и заявлениями сторон. Ответ — структурированный вердикт: рекомендация (refund, release или split), обоснование и показатель уверенности.

Вердикт AI не является обязательным. Это рекомендация, которую видят обе стороны. Ни контракт в блокчейне, ни сервер не действуют на его основе автоматически.

Этап 4 — Принятие

Если обе стороны согласны с вердиктом AI или проигравшая сторона признаёт решение, разрешение становится локальной операцией в браузере. Сторона, признающая поражение, подписывает транзакцию release или refund прямо в браузере — ключи никогда не покидают устройство. В случае разделения обе стороны создают частичные подписи, которые сервер объединяет в транзакцию mutual.

Это оптимистичный путь — без участия арбитра, только комиссия за спор. Контракт также поддерживает ещё более простой случай: если всё окно спора истекает без подачи спора, таймаутный путь autoRelease выплачивает средства продавцу автоматически. Серверный вотчер транслирует эту транзакцию.

Этап 5 — Арбитраж от человека

Если ни одна сторона не принимает вердикт AI в течение настроенного окна (по умолчанию 24 часа), система передаёт дело арбитру-человеку. Арбитр получает доступ к специализированной веб-панели с двухфакторной аутентификацией (nginx basic auth плюс либо подпись Telegram initData, либо админский токен).

Панель показывает полную временную шкалу: оба заявления, расшифрованную переписку с закреплениями сообщений в блокчейне, вердикт AI с обоснованием, все доказательства расследования и статус OTC-верификации. Арбитр выносит обязательное решение, подписывая одну из трёх транзакций локально в браузере:

arbitrateToBuyer(arbSig)   → 100% покупателю
arbitrateToSeller(arbSig)  → 100% продавцу  
arbitrateSplit(arbSig)     → произвольная пропорция, каждый выход ≥ 1 KAS

Приватный ключ арбитра — оффлайн-строка из 64 hex-символов. Она попадает в браузер только на момент подписания и немедленно стирается. На сервере хранится только публичный ключ. Если ключ арбитра утерян, оспариваемые сделки разрешаются только через таймаут на уровне контракта — именно вокруг этого и построена вся система безопасности.

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

Весь стек разрешения споров работает внутри одного процесса на Rust/axum (порт 8795), который также обслуживает Kaspa Safe, маркетплейс и сделки с депозитами. Ключевые модули:

• dispute_api.rs — HTTP-маршруты для claim, reveal, escalate, опроса состояния и сбора взаимных подписей.
• arbiter.rs — AI-медиатор: реконструирует расшифровку переписки из раскрытых ключей, вызывает LLM, парсит структурированный JSON-вердикт.
• media_probe.rs — движок расследования, обрабатывающий изображения, видео, документы, отслеживание доставки и кросс-чейновую OTC-верификацию.
• watcher.rs::run_escrow — цикл опроса каждые 10 секунд, обрабатывающий автоматический выпуск после окон споров, таймаутные выплаты после дедлайнов арбитра и предупреждения обеим сторонам при 50% и 90% истечения окна.

У арбитра также есть Telegram Mini App-хаб в приватном боте для удобного управления делами с мобильных устройств. Все уведомления — Telegram, email и web push — рассылаются из единой функции отправки. Контракт эскроу компилируется из escrow.sil в WASM-ядро на этапе сборки; билдеры транзакций для всех десяти путей переиспользуются как браузером (через WASM), так и сервером (как rlib). Набор из 52 автотестов проверяет каждый путь расходования в виртуальной машине Kaspa.

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

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

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

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

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

Глубина расследования зависит от шаблона сделки. Сделки с товарами выигрывают от отслеживания доставки и анализа фотографий; OTC-сделки получают кросс-чейновую верификацию встречной стороны через 17 блокчейн-сетей. Сделки с услугами и цифровыми товарами больше полагаются на доказательства из чата, где текстовый анализ AI-медиатора выполняет основную работу.