Как Kaspa Marketplace превращает каждое объявление в ончейн-сделку с эскроу

Групповые чаты Telegram по-прежнему остаются основной площадкой для P2P-сделок с криптовалютой во многих сообществах Kaspa. Покупатель отправляет KAS «гаранту» — незнакомцу с закреплённым сообщением и рейтингом — и надеется, что продавец отправит товар. Гарант держит реальные деньги. Если он исчезает — исчезают и деньги.

Kaspa Marketplace идёт принципиально иным путём: он оборачивает каждое объявление в полноценную ончейн-сделку с эскроу. Средства никогда не хранятся у оператора, продавца или какого-либо посредника. Они находятся в ковенанте Toccata — ончейн-скрипте, правила расходования которого проверяются каждым узлом Kaspa на уровне консенсуса.

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

Ковенант эскроу: что под капотом

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

Контракт находится на P2SH-адресе, выведенном из трёх публичных ключей: покупателя, продавца и арбитра. Он компилируется из исходного файла Silverscript escrow.sil и развёрнут ончейн через опкоды интроспекции транзакций Toccata.

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

Окна спора измеряются в DAA-скорах — монотонно возрастающем счётчике, привязанном к корректировке сложности Kaspa, а не к реальному времени. Это делает тайм-локи невосприимчивыми к манипуляциям с метками времени.

Три свойства безопасности обеспечивают надёжность для маркетплейса:

1. Инвариант единственного входа. Каждый путь начинается с require(tx.inputs.length == 1), что блокирует атаку слияния нескольких UTXO, при которой два выхода на одном P2SH-адресе объединяются, а избыточная стоимость утекает в комиссии. 2. Ограничение злоупотребления комиссиями. Параметр feeBudget (максимум 0,1 KAS ончейн) не позволяет никому сжечь стоимость эскроу завышенной сетевой комиссией на пути без подписи. 3. Сохранение средств на арбитражных путях. Разделение арбитра явно проверяет out0 + out1 >= in - feeBudget, так что средства не могут незаметно исчезнуть.

Полный анализ контракта представлен в наших разборах «Пути расходования эскроу» и «Безопасность ковенантов».

Анатомия объявления: Черновик → Резерв → Обеспечение → Завершение

Маркетплейс не изобретает новый контракт. Он добавляет слой витрины — менеджер жизненного цикла — поверх существующей инфраструктуры эскроу.

1. Продавец публикует

Продавец заполняет форму: категория (товары, цифровое, OTC, услуги), цена (минимум 50 KAS, без верхнего лимита), предустановка окна спора и до трёх фотографий. Под капотом функция create_listing выполняет два действия атомарно:

• Создаёт черновик сделки с эскроу через ту же функцию Deals::create_deal, что используется для автономных транзакций эскроу.
• Генерирует одноразовый код присоединения, привязанный к этому черновику.

ИИ-модерация отмечает нарушения правил до того, как объявление появится на витрине. Сама витрина рендерится на стороне сервера с метаданными JSON-LD и Open Graph для видимости в поисковых системах.

2. Покупатель присоединяется

Когда покупатель нажимает «Купить через эскроу», маркетплейс передаёт ему код присоединения. Это запускает стандартный процесс: публичный ключ покупателя добавляется к параметрам сделки, сервер вычисляет P2SH-адрес эскроу из обоих ключей плюс ключа арбитра, и покупатель видит адрес для пополнения и точную сумму.

Теперь объявление зарезервировано — скрыто с витрины, чтобы второй покупатель не мог присоединиться повторно. Резерв действует один час. Если покупатель не пополнит счёт за это время, сделка истекает, а объявление автоматически публикуется заново с новым кодом присоединения.

3. Обеспечение, доставка, завершение

Как только покупатель отправляет KAS на адрес эскроу и наблюдатель подтверждает UTXO, сделка считается обеспеченной:

• Активируется чат сделки — сквозные зашифрованные сообщения, закреплённые в BlockDAG через протокол Kasia. Каждое сообщение — это полезная нагрузка ciph_msg:…, хеш транзакции которой служит защищённой от подделки меткой времени.
• Продавец доставляет товар или оказывает услугу. Для физических товаров данные доставки передаются через чат. Для цифровых товаров (см. ниже) сам доставляемый контент передаётся здесь.
• Покупатель проверяет и либо подтверждает оплату (подписывает путь release), либо открывает спор (подписывает dispute, активируя окно арбитра).
• Если ни одна сторона не предпринимает действий, наблюдатель транслирует autoRelease без подписи после окна спора — средства поступают продавцу, а комиссия — на адрес комиссии. Подпись никого не требуется, поскольку ковенант уже содержит оба адреса назначения.

Когда UTXO расходуется, наблюдатель фиксирует это и либо публикует объявление заново (для многоразовых цифровых товаров), либо закрывает его.

Предварительный чат: переговоры без расходования кода присоединения

Маркетплейс поддерживает чат объявления, который существует до создания какой-либо сделки. Потенциальный покупатель может спросить о доставке, характеристиках или особых условиях — всё со сквозным шифрованием.

Ключевая архитектурная деталь: ключи чата объявления выводятся для комбинации listing × buyer-token, а не для deal_id. Это важно, потому что код присоединения одноразовый. Использовать его на разговоре, который не приведёт к покупке, — значит заставить продавца создавать новый черновик. Чат объявления позволяет покупателям свободно торговаться, не расходуя процесс эскроу. Только когда покупатель решает совершить покупку, он переходит в чат сделки, привязанный к реальному обеспеченному ковенанту.

Цифровые товары: электронная доставка через BlockDAG

Значительная часть P2P-сделок — цифровые: лицензии на ПО, API-ключи, токены доступа, подарочные карты. Маркетплейс сопоставляет их с объявлениями типа «услуги» с template_id=digital-goods, что меняет несколько параметров по умолчанию:

• Многоразовые по умолчанию. Объявление публикуется заново после каждой завершённой сделки, поскольку продавец может снова доставить тот же тип товара.
• Окно спора 48 часов — короче, чем для физических товаров, поскольку доставка мгновенная.
• Нет полей географии, службы доставки или отслеживания. Доставка происходит полностью через чат сделки со сквозным шифрованием.
• Продавец прикрепляет доставляемый контент в виде зашифрованного медиа-сообщения. Файлы шифруются для каждого вложения уникальным ключом; SHA-256-хеш закрепляется в BlockDAG, чтобы покупатель мог проверить целостность до подтверждения оплаты.

Наблюдатель: оффчейн-машина состояний для ончейн-контрактов

Единственный фоновый процесс — наблюдатель — опрашивает узел Kaspa каждые 10 секунд и управляет как хранилищами Safe, так и сделками с эскроу, включая объявления маркетплейса. Для объявлений он обрабатывает:

• Истечение черновиков для объявлений, к которым никто не присоединился.
• Тайм-аут резерва: если присоединённая сделка не обеспечена за 3600 секунд, сделка истекает, а объявление публикуется заново.
• Авто-подтверждение: после окна спора наблюдатель транслирует транзакцию autoRelease без подписи.
• Тайм-аут: после дедлайна арбитра наблюдатель транслирует транзакцию тайм-аута без подписи.
• Перепубликация: когда сделка по многоразовому объявлению закрывается, наблюдатель создаёт новый черновик и код присоединения.
• Уведомления: оповещения на 50% и 90% окна спора, а также за ~20% до дедлайна арбитра — через Telegram, электронную почту и веб-уведомления.

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

Структура комиссий

Комиссии делятся на два уровня, обеспечиваемых выходом feeSpk ковенанта:

Параметр feeBudget — максимальная сетевая комиссия, которую ковенант допускает на путях без подписи — ограничен диапазоном от 0,01 до 0,1 KAS в продакшене. Это предотвращает атаку, при которой кто-то транслирует путь без подписи с абсурдно высокой комиссией, сжигая стоимость эскроу в виде награды майнеру.

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

Рекомендательная кросс-чейн верификация, не обязательная. Для OTC-сделок с другими сетями (USDT в Tron, BTC и т.д.) сервер может автоматически верифицировать заявленный ID транзакции через публичные блокчейн-обозреватели — до 17 комбинаций сетей и методов. Но это *рекомендательный сигнал*: зелёный значок «этот txid выглядит корректным». Покупатель по-прежнему подтверждает оплату вручную. Ончейн-ковенант не осведомлён о других блокчейнах.

Фиатные сделки происходят полностью в чате. Нет интеграции на уровне контракта с банковскими переводами или платёжными провайдерами. Данные фиатного платежа и подтверждение перевода передаются в чате со сквозным шифрованием. Ковенант знает только то, что KAS был помещён в эскроу.

Нет ончейн-метаданных объявлений. Само объявление — заголовок, описание, цена, фотографии — хранится в базе данных сервера, а не в BlockDAG. Ковенант хранит только параметры эскроу (ключи, окна, комиссии). Если сервер исчезнет, содержимое объявлений будет потеряно, но средства в эскроу останутся доступными для расходования через пути ковенанта без подписи и оффлайн-инструменты восстановления, такие как vaultctl.

ИИ-модерация — это фильтр, а не гарантия. Маркетплейс запускает ИИ-модерацию для новых объявлений, чтобы отлавливать очевидные нарушения правил. Она снижает объём спама и мошенничества, но не заменяет осторожность покупателя. Чат со сквозным шифрованием означает, что сервер не может модерировать переписку в сделке — это сделано намеренно, ради приватности.

Минимум 50 KAS на объявление. Ниже этого порога комиссии за разрешение споров (минимум 5 KAS) «съедают» более 10% стоимости сделки, делая экономику нецелесообразной.

Однопроцессная архитектура. Маркетплейс разделяет один и тот же процесс на Rust, базу данных SQLite и цикл наблюдателя с Kaspa Safe и автономным Escrow. Это упрощает эксплуатацию, но означает, что один перезапуск затрагивает все продукты. Ончейн-средства никогда не подвергаются риску — ковенанты существуют независимо от любого сервера, а оба контракта включают пути без подписи, которые переживают полный отказ сервиса.