Зашифрованная синхронизация кошелька Kaspa с Profile Mirror

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

Profile Mirror Kaspa Forge решает это с ограничением, которое определяет каждое проектное решение: сервер синхронизации никогда не должен хранить ничего, что можно расшифровать. Он хранит шифротекст. Точка. Profile Mirror доступен в Desk как явная опция бета-версии — вот как работает механизм зашифрованной синхронизации кошелька Kaspa под капотом.

Проблема: Самостоятельное хранение на нескольких устройствах

У каждого пользователя Kaspa Forge есть один зашифрованный профиль: блок данных, содержащий ключи HD-кошелька, записи хранилищ, сделки эскроу, позиции депозитов, объявления маркетплейса, ключи публикаций на досках и состояние интерфейса. Desk блокирует этот профиль паролем с помощью WebCrypto. Ключи никогда не покидают устройство.

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

Profile Mirror находится между этими полюсами: он синхронизирует устройства, гарантируя, что сервер хранит только данные, которые бесполезны без пароля пользователя.

Шаг 1 — Генерация идентичности синхронизации

Перед синхронизацией сервер должен понять, *какой* профиль ассоциировать с вашим запросом. Но отправка вашего адреса кошелька утечка приватности, а отправка приватного ключа полностью исключена.

Profile Mirror генерирует идентичность синхронизации детерминированно из вашего исходного ключа кошелька. Функция WASM forge_sync_identity() применяет HMAC-SHA512 с разделением доменов, создавая единый стабильный якорь. Из этого следуют два свойства:

• Детерминированность. Один и тот же ключ кошелька всегда генерирует одну и ту же идентичность, независимо от устройства. Если вы создали профиль Desk на ноутбуке, а затем открыли Desk на телефоне с той же seed-фразой, оба устройства независимо вычислят одну и ту же идентичность синхронизации и найдут один и тот же слот на стороне сервера.
• Независимость от адреса. Смена вашего адреса для получения средств — которую Desk выполняет после каждой публикации на Досках и по запросу — не меняет якорь. Идентичность привязана к корневому дивайсу ключа, а не к какому-либо конкретному адресу wallet/<index>.

Сырой ключ кошелька никогда не касается сети. Он не подписывает запросы API. Генерация идентичности происходит полностью внутри браузерной среды WASM.

Шаг 2 — Проекция: Отсечение того, что должно оставаться локальным

Не всё в профиле Desk должно передаваться — даже в зашифрованном виде — на общий сервер. Некоторые ключи по замыслу привязаны к устройству.

Перед шифрованием mirrorProjection() строит проекцию локального профиля. Это трансформация только для чтения, которая не изменяет локальные данные на диске. Проекция явно удаляет:

• alarm_sk — ключ сигнализации, который может отменить вывод из Kaspa Safe. Этот ключ должен оставаться на устройстве, создавшем хранилище; его синхронизация позволила бы второму устройству отменять выводы, которые должны быть привязаны к устройству.
• heir_sk — ключ наследования для хранилищ типа «проверка или наследование».
• arbiter_sk — ключ разрешения споров для сделок Escrow.
• Все arenaCanaryKeys — ключи для каждой комнаты, используемые при подписании игр Арены.

Ворота проверки с закрытым отказом (fail-closed) проверяют проекцию перед шифрованием: если ворота не могут подтвердить отсутствие этих ключей, загрузка синхронизации прерывается. Нет пути в коде, который случайно включит их.

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

Шаг 3 — Двухслойное шифрование

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

1. Шифрование age — тот же формат, что используется для файлов экспорта .age. Это внутренний конверт. 2. AES-256-GCM (через WebCrypto) — внешний конверт, ключ которого выводится из пароля пользователя через ту же KDF, что используется для шифрования локального профиля.

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

Ни в один момент сервер не владеет ключом дешифрования, полем в открытом виде или seed-фразой. Если кто-то взломает сервер зеркала, он получит непрозрачные блоки и подписи — бесполезные без пароля, который никогда не передавался.

Шаг 4 — Обновления «сравни и обменяй»

Два устройства, синхронизирующиеся с одним серверным слотом, нуждаются в способе не перезаписывать изменения друг друга. Profile Mirror использует семантику «сравни и обменяй» (CAS): каждая запись должна предъявить previous_hash версии, которую клиент прочитал последней. Если сервер продвинулся с момента того чтения, запись отклоняется.

Представьте конфликт редактирования вики. Вы получаете версию 7, вносите изменения и пытаетесь отправить версию 8 — но кто-то уже отправил свою версию 8, пока вы редактировали. Ваша отправка проваливается, вы заново получаете данные (теперь версия 8), объединяете локально и отправляете версию 9.

Сервер хранит 512 версий каждого профиля. Если устройство отключается на длительный срок и выпадает из окна версий, подписанная цепочка рвется — клиент не может построить действительное доказательство CAS. Восстановление тогда требует отката из резервной копии на стороне сервера, а не от клиента. Это осознанный компромисс: окно хранения достаточно велико для обычного использования на нескольких устройствах, а неограниченная история увеличила бы как затраты на хранение, так и площадь атаки.

Каждая загрузка также несет nonce запроса для предотвращения атак с повторным воспроизведением. Повторное воспроизведение захваченного блока провалило бы проверку CAS (версия сервера продвинулась) *и* проверку nonce.

Шаг 5 — Детерминированное слияние

Когда устройство получает более новую версию из зеркала, оно запускает mergeProfile — детерминированную функцию, которая объединяет локальное и удаленное состояние. Логика слияния оперирует стабильными идентификаторами:

• Хранилища объединяются по их адресу ковенанта в блокчейне.
• Сделки эскроу объединяются по ID сделки.
• Ключи заявок на досках объединяются по ephemeral_pk.
• Могильные метки (маркеры удаления) сохраняются: если вы удалили хранилище на устройстве А, могильная метка синхронизируется на устройство Б, которое затем также удаляет хранилище при слиянии, а не воскрешает его из старого снимка.

Для предотвращения ложных конфликтов хеш профиля, который определяет, действительно ли различаются локальное и удаленное состояния, сравнивает каноническое логическое состояние, а не сырые байтовые последовательности JSON:

• wallet и walletOld рассматриваются как единый отсортированный пул ключей/адресов. Локальная для устройства роль активного/архивного не влияет на хеш.
• prefs (настройки интерфейса, такие как тема, отображаемое имя) исключаются. Два устройства могут иметь разные настройки интерфейса без вызова ненужных загрузок синхронизации.
• Коллекции идентичностей сортируются перед хешированием.

Устройства сходятся на общем криптографическом состоянии, сохраняя свои собственные особенности интерфейса локальными.

Шаг 6 — Автосинхронизация vs. Ручная синхронизация

После подключения опции пользователь может отдельно включить Автосинхронизацию при разблокировке. Это устанавливает локальный для устройства флаг (localStorage), который запускает синхронизацию после открытия разблокированного Desk — но не чаще одного раза в 15 минут на профиль, через вкладки и полные перезагрузки страницы. Автосинхронизация не запрашивает подтверждение; если слияние проходит успешно, оно молчаливо. Ошибки остаются в панели состояния синхронизации.

Ручная Синхронизация сейчас всегда доступна, обходит период ожидания, запрашивает пароль и показывает явное подтверждение слияния, если есть входящие изменения. Это путь для пользователей, которые хотят видеть, что изменилось.

Автосинхронизация — это локальная настройка. Она не синхронизирует саму себя в профиль, не включает Mirror на других устройствах и не запускает фоновый опрос.

Как Kaspa Forge использует Profile Mirror

Profile Mirror стоит за Desk и затрагивает каждый продукт, который хранит состояние в зашифрованном профиле:

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

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

Ни один дизайн не бывает бесплатным. Profile Mirror делает явные компромиссы:

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

Хранение в 512 версий конечно. Устройство, которое остается отключенным месяцами, может выпасть из окна версий. Разрыв нельзя восполнить на стороне клиента — восстановление требует отката из ежедневной резервной копии сервера. Окно настроено для обычного ритма использования на нескольких устройствах, а не для архивирования.

Автосинхронизация по замыслу «отправил и забыл». Она не показывает подтверждений слияния, что означает, что пользователь, который ее включает, доверяет детерминированному слиянию сделать всё правильно. Для большинства пользователей это верно; для продвинутых пользователей, которые хотят проверять каждое слияние, ручная Синхронизация сейчас — подходящий инструмент.

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

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

---

Базовый принцип прост: сервер синхронизации, который не может расшифровать ваши данные, — это сервер синхронизации, который не может вас предать. Profile Mirror достигает этого, объединяя детерминированную генерацию идентичности, исключение ключей на основе проекции, двухслойное шифрование и версионирование «сравни и обменяй» — всё реализовано в браузерных WASM и WebCrypto, где сервер выступает в роли глупого зашифрованного журнала. Публичная вики Kaspa охватывает базовые протокольные примитивы (структуру транзакций, модель UTXO, расчет комиссий), которые делают возможными операции в блокчейне; Profile Mirror обрабатывает слой координации вне блокчейна, который поддерживает согласованность вашего зашифрованного состояния Desk на разных устройствах, никогда его не раскрывая.