Как Kaspa Forge связывает четыре инструмента в единую некастодиальную структуру

Большинство криптоплатформ, предлагающих несколько финансовых инструментов — хранилище, эскроу-сервис, маркетплейс, — запускают их как отдельные микросервисы. У каждого своя база данных, свой конвейер развертывания, свой уровень аутентификации. Это общепринятый инженерный подход.

Kaspa Forge выбирает другой путь. Kaspa Safe, Kaspa Escrow, Kaspa Deposit и Kaspa Marketplace работают на едином процессе Rust-сервера, используя одну базу данных SQLite и один зашифрованный профиль пользователя в браузере. Нет внутренних вызовов API между сервисами, потому что нет отдельных сервисов.

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

Почему один процесс вместо четырех

Микросервисы существуют для решения проблем координации: отдельные команды, отдельные потребности в масштабировании, отдельные области отказа. У Kaspa Forge этих проблем нет.

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

Хардфорк Toccata принёс ковенанты в основную сеть Kaspa, а вместе с ними — возможность кодировать сложные правила расходования прямо в скриптах UTXO. Это значит, что сервер не хранит средства и не обеспечивает правила — ему нужно только строить валидные транзакции и наблюдать за сетью. Один процесс может делать это для любого количества инструментов.

Общий WASM-крейт

Технический краеугольный камень — это единый крейт Rust, скомпилированный двумя способами:

• cdylib (динамическая библиотека) → компилируется в WebAssembly через wasm-pack, загружается в браузере
• rlib (статическая библиотека) → линкуется в бинарный файл сервера

Обе копии содержат одни и те же конструкторы транзакций: пути хранилища (initiate, cancel, complete, checkin, inheritAuto, inheritSigned, migrate), пути эскроу (release, refund, dispute, autoRelease, arbitrate*, timeout*, mutual), вывод HD-ключей и вычисление адресов. Когда пользователь нажимает "Снять" в браузере, модуль WASM строит и подписывает транзакцию на стороне клиента. Когда наблюдатель сервера инициирует autoRelease или complete, тот же код Rust строит транзакцию на стороне сервера.

// Same function, same logic, same correctness proof —
// whether called from WASM bindings or from the server binary
fn build_vault_complete_tx(utxo, dest, fee_budget) -> Transaction { ... }

Одна поверхность аудита. Один набор тестов. Если путь complete работает в браузере, он работает и на сервере, потому что это одна и та же функция, скомпилированная в другую цель.

Крейт также включает компилятор Silverscript, поэтому скрипты ковенантов компилируются из исходников во время сборки через макрос Rust include_str! — контракты vault.sil и escrow.sil встраиваются в бинарный файл, а не загружаются из файловой системы в рантайме. Изменение исходника контракта вызывает перекомпиляцию как браузерного WASM-бандла, так и бинарного файла сервера — именно такое поведение нужно, когда на кону правила расходования чьих-то средств.

Один SQLite, несколько реестров

Сервер работает с одним файлом SQLite. Каждый инструмент открывает свой пул соединений к этому файлу — реестр хранилищ, реестр сделок (общий для Escrow и Deposit, так как Deposit повторно использует тот же десятипутевой эскроу-ковенант), реестр листингов для маркетплейса и журнал обменов.

Схема определяется встроенно с помощью CREATE TABLE IF NOT EXISTS и идемпотентных операторов ALTER TABLE. Никаких внешних инструментов миграции. Это сознательный выбор простоты: SQLite хорошо справляется с текущей нагрузкой, атомарные записи предотвращают кросс-инструментальную несогласованность, а резервное копирование одного файла захватывает всё состояние приложения.

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

Desk: один зашифрованный профиль

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

Когда пользователь создаёт хранилище через Kaspa Safe, Desk генерирует мастер-сид и выводит ключ hot, ключ alarm и ключ funding с использованием HMAC-SHA512 с доменной сепарацией:

HMAC-SHA512(
  key  = master_seed,
  msg  = "kaspaforge/v1/vault/<index>"
) → first 32 bytes = secret key

Когда тот же пользователь открывает сделку Escrow, Desk выводит отдельный чат-ключ и ключ стороны эскроу из того же сида, используя другую доменную строку. Один сид. Один зашифрованный резервный файл .age под пользовательской парольной фразой. Все текущие и будущие ключи восстанавливаемы — даже ключи для хранилищ и сделок, созданных *после* создания резервной копии, потому что вывод детерминирован, а индекс монотонно возрастает.

Зашифрованный профиль (версия 3) хранит ключевой материал для каждого инструмента: для каждого хранилища — секретный ключ hot, секретный ключ alarm (или флаг, указывающий, что ключ alarm хранится на физической карточке), ключ funding, бюджет комиссии и пользовательскую заметку. Ключи никогда не покидают браузер. Сервер получает только публичные ключи и подписанные транзакции. С сервера нечего красть, потому что там нет ничего конфиденциального.

Безопасность сессии применяется глобально: таймер автоматической блокировки, повторное подтверждение пароля при любой операции подписания (с отображением конкретной суммы и получателя в качестве контекста) и защита при загрузке, требующая разблокировки при каждой загрузке страницы. Ключевой файл .age — единственная портативная копия, зашифрованная по схеме passphrase на основе scrypt от age, в ASCII-обёртке, совместимая со стандартным CLI age -d для офлайн-дешифровки.

Циклы наблюдателей: один сервер, параллельный мониторинг

Сервер запускает два фоновых цикла наблюдателей, каждый с циклом в 10 секунд:

1. Наблюдатель хранилищ — сканирует все зарегистрированные UTXO хранилищ, сравнивает со сохранёнными снимками, инициирует оповещения (обнаружен депозит, начато снятие, отмена, завершение), отправляет напоминания о проверке, когда таймер наследования приближается к 80% задержки, и автоматически рассылает транзакции complete или inheritAuto, когда их бесключевые пути становятся валидными. Он опирается на счетчики DAA — монотонно возрастающий счётчик, отслеживающий синие блоки и успешно объединённые красные блоки (как описано в вики Kaspa), — чтобы определить, когда созрел тайм-локированный путь.

2. Наблюдатель эскроу — сканирует UTXO эскроу и депозитов, обрабатывает весь жизненный цикл сделки (истечение черновика, автоматический релиз после окна спора, тайм-аут после дедлайна арбитра), управляет бронированием и републикацией листингов маркетплейса и эскалирует нерешённые AI-вердикты человеку-арбитру через 24 часа.

Оба цикла разделяют одно gRPC-соединение с узлом Kaspa. Оба используют одну инфраструктуру уведомлений — Telegram-бот, электронную почту и веб-пуш. Единый сервис уведомлений рассылает по всем каналам, независимо от того, какой инструмент инициировал событие.

Здесь-то и проявляется выгода архитектуры с одним процессом: нет проблемы "какой сервис владеет очередью уведомлений", нет распределённых блокировок на снимках UTXO, нет логики повторных попыток для межсервисных вызовов. Наблюдатель видит полную картину, потому что он *и есть* полная картина.

Как Kaspa Forge использует это на практике

Практический результат для пользователей — бесшовная кросс-инструментальная работа в рамках одного зашифрованного профиля.

Пользователь создаёт хранилище через Kaspa Safe, открывает сделку эскроу через Kaspa Escrow и выставляет товар на маркетплейсе — всё из одного Desk. Листинг маркетплейса подкреплён реальной сделкой эскроу на том же ковенанте escrow.sil. Deposit повторно использует те же десять путей расходования с по-другому отображёнными ролями: вкладчик отображается на роль seller ковенанта, держатель — на роль buyer, а стандартные механики релиза, возврата и тайм-аута применяются как есть.

Дизайн ковенантов делает эту композицию возможной. Инвариант единого входа, обеспечиваемый во всех 17 путях расходования (7 хранилищ + 10 эскроу), предотвращает атаки на высасывание нескольких UTXO. Лимит feeBudget предотвращает атаки на комиссии в бесключевых транзакциях. Эти ограничения действуют во всех инструментах, потому что все инструменты разделяют один исходник контракта и один конвейер сборки.

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

Архитектура с одним процессом имеет реальные издержки:

• Единая область отказа. Сбой сервера выводит из строя сразу все четыре инструмента. Это смягчается тем, что средства находятся on-chain — сбой сервера задерживает уведомления и рассылку бесключевых транзакций, но не угрожает сохранённой стоимости. Open-source CLI vaultctl и escrowctl могут управлять средствами через любой публичный узел Kaspa.

• Потолок SQLite. Текущая база данных хорошо справляется с нагрузкой, но горизонтальное масштабирование потребует другого слоя хранения. Это проблема будущего, а не настоящего.

• Поколения снимков WASM. На стороне браузера используются несколько замороженных сборок WASM (обозначенных как v3, v5, v7, v8 в каталогах ресурсов) для разных контекстов страниц — страницы Safe загружают одну сборку, страницы Escrow — другую, React Desk — третью. Каждое поколение представляет собой скомпилированный снимок крейта с экспортом определённых привязок. Добавление нового экспорта в неправильное поколение вызывает ошибку "function is not a function" только на некоторых страницах. Этим тщательно управляют, но это постоянные издержки на сопровождение.

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

Фундаментальный инсайт в том, что ковенанты переносят границу доверия в сеть. Сервер не обеспечивает правила; это делает блокчейн. Задача сервера — строить валидные транзакции и рассылать их в нужное время. Эта задача не требует микросервисов; она требует корректности в одном месте, что проще проверить с одним крейтом, одним набором тестов и одной поверхностью аудита.