Как устроен не-кастодиальный стек Kaspa Forge

Kaspa Forge — это не-кастодиальная платформа, построенная на уровне ковенантов Toccata в Kaspa. Семейство продуктов — хранилища Safe, Escrow для P2P-сделок, Deposit для залогов, маркетплейс, публичные доски Boards, Arena Blackjack и кошелёк Desk — использует единый архитектурный стержень: зашифрованный браузерный профиль, хранящий ваши ключи, криптографическое ядро на Rust с компиляцией в WASM, которое подписывает каждую транзакцию локально, ончейн-ковенантные контракты, обеспечивающие правила на уровне протокола, и серверный слой, который индексирует состояние, но никогда не касается приватных ключей. В этой статье мы разберём каждый слой, обозначим границы доверия между ними и честно укажем на текущие ограничения продуктов.

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

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

Пять слоёв — одна архитектура

Платформа разбивается на пять слоёв, каждый с собственной ролью и чёткой границей к следующему:

1. Ключи в браузере — зашифрованный профиль Desk и HD-мастер-сид 2. Криптографическое ядро WASM — kaspa-safe-core, единый Rust-крейт, скомпилированный для браузерных и серверных целей 3. Ковенантные деньги — контракты Toccata, исполняемые ончейн нодой Kaspa 4. Сервер и индексатор — API, зеркало профиля, уведомления, ретрансляция транзакций 5. Нода Kaspa — консенсус BlockDAG, состояние UTXO, исполнение ковенантных скриптов

Далее в статье мы подробно разберём каждый слой.

Слой 1 — Ключи в браузере: профиль Desk

Каждый продукт Kaspa Forge начинается с одного и того же зашифрованного профиля, которым управляет Desk. Текущий формат профиля (версия 3) содержит:

• HD-мастер-сид, из которого выводятся все ключи. Путь деривации следует шаблону kaspaforge/v1/vault/<index>, поэтому один сид покрывает каждое хранилище, каждую эскроу-сделку и каждую игровую идентичность Arena, которую пользователь создаст, — включая будущие, ещё не созданные.
• Секретные ключи для каждого продукта: hot_sk для вывода владельцем, alarm_sk (или флаг, указывающий, что тревожный ключ хранится на физической карте за пределами профиля) и funding_sk для операций пополнения.
• Адреса кошелька — текущий адрес для получения (wallet) и предыдущие адреса (walletOld). Баланс — это сумма UTXO по всем адресам. Каждый вход подписывается своим ключом; сдача возвращается на текущий адрес.
• Файл ключей .age — единственная переносимая копия всего профиля, зашифрованная инструментом age с паролем scrypt, в ASCII-формате и совместимая с консольной утилитой age -d.

master seed
  │
  ├─ kaspaforge/v1/vault/0   →  vault #0 keys
  ├─ kaspaforge/v1/vault/1   →  vault #1 keys
  ├─ kaspaforge/v1/vault/2   →  escrow keys
  └─ ...

Безопасность сессии обеспечивается на уровне страницы. Защита при запуске (requireUnlock) требует ввода пароля перед загрузкой любого продукта. Операции вывода и подписи вызывают повторный запрос пароля с отображением точной суммы и получателя. Сессия автоматически блокируется после 15 минут бездействия.

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

Слой 2 — Один Rust-крейт, две цели

Все криптографические операции — генерация ключей, HD-деривация, формирование транзакций, компиляция ковенантов, шифрование .age и шифрование чата — реализованы в едином Rust-крейте под названием kaspa-safe-core. Он компилируется в две цели:

• cdylib через wasm-pack build --target web → браузерный WASM-бандл, загружаемый каждой страницей продукта.
• rlib → линкуется в серверный бинарник для операций, требующих той же логики на стороне сервера (валидация транзакций, синхронизация профиля).

Крейт зависит от silverscript-lang (компилятора ковенантов), rusty-kaspa-крейтов, закреплённых на теге v2.0.1, secp256k1, стека ECIES-шифрования для чата и библиотеки age для шифрования профиля.

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

Рабочий Desk в настоящее время загружает WASM-поколение v9, которое добавляет точный фиксированный расчёт комиссий для отправки с кошелька — браузер считывает текущую ставку комиссии ноды, формирует подписанную транзакцию в WASM и вычисляет нормализованную комиссию в сомпи без искусственного порога. Старые продукты — стандартные страницы Safe (v3) и страницы Escrow/Deposit (v5) — привязаны к своим неизменяемым снимкам того же крейта. Каждое поколение — замороженная сборка; новый экспорт получает собственную директорию и путь импорта, чтобы избежать конфликтов кеша браузера, когда одна страница загружает функцию, которую бандл другой страницы не экспортирует.

Слой 3 — Ковенантные деньги на BlockDAG

Сами деньги находятся в ковенантных UTXO Toccata на блокчейне Kaspa BlockDAG. Вики Kaspa описывает, как консенсус GHOSTDAG упорядочивает блоки и транзакции; ковенантные скрипты исполняются скриптовым движком ноды в рамках обычной валидации транзакций.

У каждого продукта свой контракт, скомпилированный из SilverScript:

• vault.sil — хранилище Safe с несколькими путями расходования: вывод владельцем (после задержки, выбранной пользователем), отмена по тревоге (отдельный ключ может отменить попытку кражи до истечения таймера), проверка наследования и автозавершение наследования. Задержка, тревожный ключ и условия наследования задаются при создании хранилища и не могут быть изменены без миграции на новый ончейн-UTXO.
• escrow.sil — контракт Escrow для P2P-сделок с путями освобождения, оспаривания, автоосвобождения и тайм-аута. Контракт Deposit использует то же ядро эскроу с другим шаблоном для залоговых сценариев.
• Ковенанты комнат и игр Arena — средства Arena Blackjack блокируются в UTXO залогов комнат и игр со своими путями расходования для входа, игры и расчёта.

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

Слои 4 и 5 — Сервер, индексатор и нода

Сервер: Бэкенд API обрабатывает индексацию (балансы, статус UTXO, состояние эскроу), сервис зеркала профиля для междевайсной синхронизации зашифрованного профиля (сервер хранит зашифрованные блоки, которые не может прочитать), push-уведомления (на основе событий, с минимальными по объёму данными) и ретрансляцию транзакций (отправку уже подписанных транзакций ноде). Сервер подключается к ноде Kaspa для запросов UTXO и состояния блоков. Он не хранит ключи, не подписывает транзакции и не формирует транзакции расходования.

Нода: Нода Kaspa с консенсусом GHOSTDAG обеспечивает золотой стандарт — актуальный набор UTXO, принятие блоков, валидацию транзакций и исполнение ковенантных скриптов. Kaspa Forge предоставляет публичную точку доступа к ноде для сценариев восстановления, но открытая утилита vaultctl может подключиться к любой ноде Kaspa v2+, а не только к ноде Kaspa Forge.

┌──────────────────────────────────────┐
│  БРАУЗЕР (ваше устройство)           │
│  Приватные ключи · HD-сид · Подпись  │
│  Ядро WASM · Шифрование профиля      │
└───────────┬──────────────────────────┘
            │ подписанные транзакции + публичные данные
┌───────────▼──────────────────────────┐
│  СЕРВЕР (Kaspa Forge)                │
│  Индексация · API · Зеркало · Ретрансляция │
│  Нет ключей · Нет подписей · Нет расходований │
└───────────┬──────────────────────────┘
            │ рассылка + запросы
┌───────────▼──────────────────────────┐
│  НОДА + BLOCKDAG (сеть Kaspa)        │
│  Консенсус · UTXO · Исполнение ковенантов │
└──────────────────────────────────────┘

Если сервер исчезнет, браузерный профиль и ончейн-контракты останутся нетронутыми. Инструменты восстановления — keyfile-decrypt.html (автономный однофайловый WASM-дешифратор, работающий офлайн по адресу file:// без единого сетевого запроса) и vaultctl (утилита с открытым исходным кодом) — восстанавливают любое хранилище с помощью любой ноды, без необходимости в бэкенде Kaspa Forge.

Как каждый продукт проходит через стек

Каждый продукт Kaspa Forge входит через один и тот же профиль Desk и ядро WASM, но направляется к разному ковенантному контракту и серверному эндпоинту:

• Kaspa Safe — Desk выводит ключи хранилища из HD-сида, ядро WASM формирует транзакцию пополнения ковенанта, и UTXO хранилища уходит в ончейн. Вывод, тревога и наследование следуют путям, определённым в vault.sil. Сервис наблюдения отслеживает таймеры и запускает автоматическое завершение при выполнении условий.
• Kaspa Escrow — две стороны открывают сделку; средства блокируются в ковенантном UTXO эскроу. Освобождение, оспаривание и тайм-аут следуют путям escrow.sil. Чат между сторонами шифруется сквозным шифрованием с использованием протокола ECIES из ядра WASM.
• Deposit — залог блокируется в ковенанте депозита с путями возврата, востребования и оспаривания. То же ядро эскроу, другой шаблон контракта. Предназначен для залогов при аренде, эскроу при выполнении работ и управления доступом.
• Маркетплейс — объявления индексируются сервером; каждая продажа направляется в отдельную эскроу-сделку. Маркетплейс никогда не хранит средства покупателя.
• Доски Boards — подписанные посты, ответы, изображения и чаевые KAS записываются в ончейн. Сервер индексирует их для отображения, но не может изменить содержимое. Модерация работает на уровне чтения, а не на уровне BlockDAG.
• Arena Blackjack (публичная бета основной сети) — ковенантные UTXO комнат и игр хранят средства игроков и дилера. Подписант Desk локально формирует и подписывает каждую транзакцию; контроллер Arena координирует игровой процесс, но никогда не касается ключей. Доказательства с нулевым разглашением верифицируют скрытую колоду и перетасовку; коммитменты и открытия Меркла обрабатывают случайность и раскрытие. Ковенанты комнат и игр — это отдельные денежные границы, не связанные с контрактами хранилищ и эскроу.
• Desk — общая точка входа. Один зашифрованный профиль, один HD-сид, одна блокировка сессии. Обзор, кошелёк, хранилища, эскроу, депозиты, доски, маркетплейс и Arena загружаются с одной поверхности.

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

Ни одна архитектура не бывает бесплатной. Вот реальные компромиссы:

• Ключи только в браузере — это и риски только браузера. Если браузер скомпрометирован вредоносным ПО или уязвимостью XSS, ключи могут быть украдены. Kaspa Forge минимизирует поверхность JavaScript и применяет политику безопасности контента (в настоящее время в режиме только отчётов), но модель угроз в конечном счёте зависит от безопасности устройства пользователя.
• HD-сид — единая точка отказа. Один мастер-сид порождает все ключи. Если резервная копия .age и пароль потеряны одновременно, восстановление невозможно. Если сид утечёт, все хранилища, эскроу и идентичности Arena будут скомпрометированы. Это стандартный компромисс иерархически детерминированных кошельков.
• Ковенанты неизменяемы после пополнения. UTXO хранилища следует путям, скомпилированным в его скрипте. Изменение параметров означает создание нового хранилища и миграцию средств — ончейн-транзакцию на новый адрес. Утилита vaultctl поддерживает такую миграцию, но платформа не может незаметно обновить активные средства.
• Статус продукта — жёсткая граница. Arena Blackjack — публичная бета основной сети: ковенантные скрипты прошли обширное тестирование (матрицы из более чем 300 кейсов, верификация консенсусных транзакций с реальными средствами на закреплённой версии Toccata), но продуктовая поверхность, ZK-инфраструктура доказательств и координация игры всё ещё укрепляются. Dice остаётся инженерной разработкой; его постоянный продакшн-филиал отложен до независимого ревью. Duel и баккара — идеи из дорожной карты, а не продукты. Токены — запланированный неразрешительный лончпад; он не запущен в основной сети.
• Восстановление зависит от доступности ноды. vaultctl работает с любой нодой Kaspa v2+, так что вы не привязаны к инфраструктуре Kaspa Forge — но вам нужна синхронизированная нода где-то. Публичная точка доступа к ноде и автономный инструмент keyfile-decrypt.html снижают эту зависимость, но не устраняют её.
• Синхронизация профиля хранит зашифрованные блоки. Сервис Forge Mirror синхронизирует ваш зашифрованный профиль .age между устройствами. Сервер не может прочитать содержимое, но он хранит шифротекст. Пользователи, предпочитающие нулевое серверное хранение, могут использовать только локальные резервные копии .age и отказаться от зеркала.

Не-кастодиальная гарантия реальна, но это не магия. Она перекладывает ответственность с платформы на операционную безопасность пользователя — надёжность пароля, дисциплину бэкапов и гигиену устройств. Kaspa Forge предоставляет инструменты (Desk, vaultctl, keyfile-decrypt.html); от пользователя требуется забота.