Как E2E-чат Kasia закрепляет зашифрованные сообщения на BlockDAG Kaspa

P2P-эскроу на блокчейне решает проблему «кто первый» — средства находятся в ковенанте, ни одна из сторон не контролирует их в одностороннем порядке. Но за ней скрывается вторая проблема: как покупатель и продавец общаются приватно в ходе сделки, и как сделать эту переписку верифицируемой, если что-то пойдёт не так?

Групповые чаты в Telegram утекают метаданные. Электронная почта централизована и допускает подтасовку. Обычный веб-чат не имеет доказательства существования — сообщение можно отредактировать или задним числом изменить дату. Ответ Kaspa Escrow — Kasia, протокол чата с сквозным шифрованием, в котором каждый коммитмент сообщения закрепляется на BlockDAG Kaspa.

Это не отдельная цепочка и не сайдчейн. Это слой поверх обычных транзакций Kaspa, который использует высокую пропускную способность DAG для проставления зашифрованных доказательств сообщений ончейн при минимальных затратах.

Разделение ключей: ключевое архитектурное решение

Первый проектный выбор оказывается самым значимым: ключи чата — это не ключи эскроу.

Каждая эскроу-сделка предполагает криптографические идентичности, управляющие ковенантом, — ключи, авторизующие пути расходования release, refund, dispute и mutual. Это высокозначимые учётные данные; потеря или раскрытие означает утрату контроля над средствами контракта.

Ключи чата генерируются отдельно для каждой сделки. Их единственная задача — шифровать и аутентифицировать сообщения между сторонами. Такое разделение даёт два важных свойства:

• Раскрытие ключа чата при споре не ставит под угрозу средства. Когда спор переходит в арбитраж, каждая сторона раскрывает свой ключ чата, чтобы переписка могла быть изучена (подробнее об этом ниже). Если бы это были те же ключи, которые управляют UTXO эскроу, медиатор или любой перехвативший мог бы попытаться авторизовать транзакции.
• Чат работает даже при нулевом балансе KAS. Сервис-кран пополняет каждый ключ чата небольшой суммой «пыли» (по умолчанию 0.5 KAS), чтобы якорная транзакция могла быть транслирована. Стороне никогда не нужен пополненный кошелёк для участия в переписке.

ECIES: как шифруются сообщения

Шифрование использует ECIES (Elliptic Curve Integrated Encryption Scheme), построенную на кривой k256 — той же семействе кривых, которое Kaspa использует для подписей транзакций, применённой здесь к обмену сообщениями.

Когда сторона отправляет сообщение, браузер:

1. Генерирует эфемерную пару ключей ECDH на k256. 2. Выводит общий секрет через ECDH между эфемерным ключом и публичным ключом чата получателя. 3. Подаёт общий секрет на вход ChaCha20-Poly1305 — симметричного AEAD-шифра, обеспечивающего одновременно шифрование и аутентификацию. 4. Упаковывает шифротекст вместе с эфемерным публичным ключом и одноразовым значением в зашифрованную полезную нагрузку.

Всё это происходит целиком в WASM-ядре браузера (модули chat_cipher.rs и chat_payload.rs, скомпилированные из kaspa-safe-core). Релейный сервер получает непрозрачный шифротекст — он никогда не видит открытого текста, эфемерных ключей или общего секрета.

Для каждого сообщения браузер отправителя создаёт два шифротекста: один зашифрован для получателя, другой — для отправителя (самокопия). Оба отправляются на релей. Транслируется только одна якорная транзакция, но каждая сторона может независимо расшифровать свою копию переписки.

Закрепление на BlockDAG: доказательство без раскрытия

Именно здесь пропускная способность Kaspa даёт практическое преимущество по сравнению с закреплением на медленной цепочке.

Для каждого переданного сообщения в BlockDAG транслируется транзакция-коммитмент с небольшой полезной нагрузкой, помеченной ciph_msg:…. Хеш транзакции (txid) становится постоянным, временным якорем, доказывающим:

• Существование — сообщение было составлено и транслировано в конкретный DAA-скор (монотонный счётчик Kaspa, сопоставимый с высотой блока, но учитывающий DAG).
• Порядок — относительные DAA-скоры устанавливают, какое сообщение было первым, что критично для хронологии спора.
• Целостность — если ончейн-якорь совпадает с хешем сообщения, содержимое не было изменено с момента доставки.

Что якорь *не* раскрывает: содержимое сообщения, личности отправителя или получателя за пределами псевдоадресов, а также метаданные сделки.

При скорости 10 блоков в секунду закрепление происходит быстро. Транзакция ciph_msg подтверждается значительно меньше чем за секунду, а комиссия ничтожна. Релей доставляет шифротекст мгновенно, и чат ощущается мгновенным; ончейн-якорь обеспечивает ретроспективное доказательство точного момента существования сообщения.

Работа с медиафайлами: файлы за той же стеной

Сделки часто включают файлы — фотографии товара, транспортные накладные, скриншоты оплаты. Kasia обрабатывает их по двухуровневой схеме:

1. Шифрование каждого файла: каждый файл получает уникальный симметричный ключ в браузере, отличный от ключа шифрования сообщений. Зашифрованный блоб загружается на сервер. 2. Дескриптор в E2E-сообщении: структурированная полезная нагрузка, содержащая ключ расшифровки файла, оригинальное имя, размер и хеш SHA-256, встраивается в обычное ECIES-зашифрованное сообщение чата. 3. Хеш-якорь в блокчейне: SHA-256 зашифрованного файла фиксируется в BlockDAG через якорную транзакцию сообщения.

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

Размер файла ограничен (60 МБ, настраивается), а пути загрузки защищены от обхода директорий. Временная обработка при криминалистике споров использует хранение только в оперативной памяти (/dev/shm), которое не переживает перезагрузку.

Структурированные сообщения: типизированные полезные нагрузки для логики сделки

Kasia поддерживает типизированные форматы сообщений помимо свободного текста, каждый из которых играет роль в жизненном цикле сделки:

Эти типизированные форматы позволяют ИИ-медиатору и арбитру механически разобрать повествование сделки. payto в паре с pay, содержащим верифицированный txid, говорит яснее, чем «я отправил, поверьте» открытым текстом. Для поддерживаемых криптовалютных сетей сервер может независимо верифицировать ончейн-идентификатор транзакции — это рекомендательный сигнал, не заменяющий решение покупателя о ручном подтверждении release, но полезный обеим сторонам и медиатору.

Для цифровых товаров (лицензии на ПО, ссылки доступа) доставка происходит через тот же E2E-канал после финансирования сделки. Транспортной компании для верификации нет — сама запись чата является доказательством доставки.

Раскрытие при споре: контролируемая передача ключей

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

1. Каждая сторона передаёт свой приватный ключ чата на эндпоинт спора. Сервер верифицирует, что он соответствует зарегистрированному публичному ключу чата стороны — подставить фальшивый ключ нельзя. 2. Сервер использует раскрытые ключи для расшифровки всей ветки сообщений, формируя транскрипт. 3. Транскрипт подаётся на вход ИИ-медиатору наряду с криминалистическим анализом медиафайлов. 4. Раскрытые ключи хранятся в оперативной памяти только на время обработки спора и не сохраняются постоянно.

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

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

Протокол обеспечивает две поверхности платформы Kaspa Forge:

Эскроу-сделки — каждая сделка Kaspa Escrow запускает свежую ветку чата с производными ключами. Покупатель и продавец общаются через панель сделки; сообщения закрепляются на уровне транзакций. Полная цепочка спора — от ИИ-медиации до человеческого арбитража — опирается на транскрипт, восстановленный по раскрытым ключам и ончейн-якорям.

Чат на маркетплейсе до сделки — прежде чем принять решение о сделке, потенциальный покупатель может написать продавцу по объявлению. Используется тот же протокол Kasia, но с ключами, производными от объявление × токен покупателя (а не от сделки), поэтому одноразовый код присоединения не расходуется ради одного вопроса. Как только покупатель вступает в сделку, переписка мигрирует в собственную ветку сделки.

На уровне реализации протокол живёт в трёх Rust-модулях, скомпилированных в WASM-ядро (kaspa-safe-core): chat_cipher.rs для ECIES, chat_payload.rs для фреймирования сообщений и media.rs для шифрования файлов и проверки хешей. Браузерные привязки (chat_bindings.rs) предоставляют их JavaScript-слою на страницах сделок. Серверный релей (chat_api.rs в едином бэкенд-процессе на :8795) обрабатывает хранение шифротекста, координацию трансляции якорей и поток раскрытия ключей в фазе спора.

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

Ончейн-закрепление не бесплатно — оно просто дешёвое. Каждое сообщение порождает транзакцию Kaspa. При текущем уровне комиссий затраты ничтожны, но кран чата целенаправленно снабжает ключ каждой стороны «пылью» для их покрытия. При очень интенсивных переговорах послочное закрепление накапливается — хотя модель комиссий Kaspa за UTXO и компактные выходы ciph_msg удерживают её минимальной.

Сервер — это релей, а не хранилище — но он всё-таки релей. Сервер не может прочитать содержимое, но теоретически *способен* удержать или задержать доставку шифротекста. Ончейн-якоря смягчают эту проблему: сообщение в окне чата без соответствующего якоря в BlockDAG вызывает подозрение. А если сервер полностью выйдет из строя, якоря сохраняют хронологию существования сообщений, даже если блобы шифротекста будут потеряны.

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

Нет прямой секретности. Текущая схема ECIES использует одну пару ключей на сделку. Если приватный ключ чата будет скомпрометирован, все сообщения, зашифрованные этим ключом, становятся читаемыми. Сигналовский Double Ratchet добавил бы ротацию ключей на каждое сообщение, но и существенное усложнение управления состоянием. Для сценария чата по сделке — краткосрочного, ограниченного жизненным циклом сделки — модель с единственным ключом представляет собой осознанный компромисс в пользу простоты.

Раскрытие — всё или ничего. Раскрытие ключа чата даёт медиатору доступ ко всей ветке; выборочного раскрытия не предусмотрено. На практике спорам нужен полный контекст, но стороны должны рассматривать чат как потенциально читаемый третьей стороной после подачи спора.

---

Протокол Kasia иллюстрирует паттерн, который становится реалистичным на высокопроизводительных PoW-цепочках: использование блокчейна не как хранилища сообщений, а как неизменяемого нотариуса. Сообщения существуют оффчейн в зашифрованном виде; BlockDAG обеспечивает метки времени и доказательства целостности. Ритм Kaspa в 10 блоков в секунду делает это практически осуществимым при пренебрежимо малых затратах — коммитмент сообщения подтверждается за время, необходимое для набора следующей строки.