Работают ли подтверждения CardanoWall офлайн?

Да — для всего, что уже есть на вашем устройстве. Как только запись Label 309, её содержимое или шифротекст и ключи для её открытия синхронизированы, CardanoWall Desktop может просматривать, искать, расшифровывать и проверять их без подключения к сети. Чего он не умеет — так это выдумывать данные, которых никогда не видел: транзакцию, которую не синхронизировал, или шифротекст, который не скачивал.

CardanoWall Desktop работает по принципу offline-first. Его локальная база данных — источник истины для того, что у вас на экране; сеть же лишь фоновый синхронизатор, который эту базу наполняет. Поэтому «офлайн» — это нормальный режим, а не ошибка: локальная машина становится рабочей копией той части мира подтверждений, которую вы уже загрузили.

Именно эта рабочая копия и делает подтверждения полезными в полевых условиях: в поездке, во время аудита, при юридической экспертизе, реагировании на инциденты или там, где связь ненадёжна. Подтверждение не должно становиться нечитаемым только из-за того, что вкладка не может достучаться до сервера. CardanoWall Desktop — это открытый код: он написан на Rust с использованием Tauri поверх открытого Rust SDK, а его исходники доступны на github.com/cardanowall, — так что вы можете увидеть, как именно он себя ведёт, а не принимать это на веру.

Что можно делать с синхронизированными подтверждениями офлайн?

Многое — при условии, что данные уже есть локально. Если это так, CardanoWall Desktop позволяет вам:

просматривать синхронизированные публичные записи Label 309;
искать в локальной зеркальной копии записей, в том числе по хешу содержимого;
просматривать записи из «Входящих», уже найденные пробным расшифровыванием;
открывать кешированный шифротекст;
расшифровывать запечатанные файлы вашими локальными ключами;
сверять хеши с локальными файлами;
проверять структуру кешированных записей;
просматривать историю отправленных записей;
готовить черновики для последующей публикации.

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

Чего нельзя делать офлайн?

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

Если транзакция никогда не синхронизировалась, приложение не может узнать о её существовании без сети или какой-то другой локальной копии её метаданных.
Если шифротекст никогда не скачивался, приложение не сможет расшифровать его офлайн.
Если запись ссылается на URI хранилища, а эти байты не были закешированы, приложение не сможет получить их без подключения.
Если вы хотите опубликовать новое подтверждение, приложению нужны шлюз и сеть: ему нужно рассчитать стоимость публикации, загрузить данные, отправить транзакцию Cardano и подтвердить её. (Публикация всегда идёт через шлюз — см. почему за публикацию берётся плата.)

Offline-first — это не обещание, что приложение восполнит недостающие данные. Это обещание, что, как только данные оказались локально, приложение относится к ним как к полноценным.

Что приложение кеширует и насколько чувствителен каждый слой?

Есть четыре слоя в порядке возрастания чувствительности.

Метаданные публичных записей. Десктоп хранит полную локальную зеркальную копию записей Label 309 — и запечатанных, и публичных — со шлюза, который вы настроили. Каждая запись невелика (метаданные одной транзакции, с запасом ниже лимита Cardano в ~16 КБ на метаданные), так что весь глобальный набор остаётся в пределах нескольких сотен мегабайт даже после многих лет активной работы. Эта зеркальная копия — основа для поиска, обнаружения входящих записей, отслеживания отправленных и офлайн-инспекции. В ней содержится только то, что и так публично доступно в блокчейне, поэтому она по замыслу хранится без шифрования — шифровать копию публичных данных бессмысленно.

Шифротекст. Запечатанные записи ссылаются на зашифрованные полезные данные через контентно-адресуемое хранилище (ar:// или ipfs://). Кешировать этот шифротекст безопасно, потому что он уже зашифрован; открыть его может только тот, у кого есть подходящий ключ. Десктоп кеширует его, чтобы повторное открытие полученного файла было мгновенным и работало офлайн.

Расшифрованное содержимое. Это чувствительный слой, и приложение обращается с ним аккуратно. По умолчанию оно расшифровывает содержимое по запросу в память и никогда не записывает открытый текст на диск. Есть необязательный, отдельно зашифрованный кеш расшифрованных файлов — для тех, кому нужны мгновенные предпросмотры без повторного открытия конверта, — но по умолчанию он выключен, а открытый текст записывается в обычное место только тогда, когда вы явно выбираете «Сохранить». Вы всегда должны знать, когда расшифрованные файлы сохраняются, где и как они защищены.

Материал идентичности. Identity Seed (сиды идентичности) хранятся в зашифрованном хранилище и разблокируются локально. Без разблокированной соответствующей идентичности запечатанная запись всё равно может появиться в зеркальной копии как публичная — просто открыть её содержимое не получится. Сам сид никогда не покидает устройство и никогда не попадает ни на один шлюз. (О том, почему эта граница важна, см. почему ключи никогда не покидают устройство.)

Можно ли проверить подтверждение офлайн?

Да — если у вас есть входные данные, которые нужны для проверки. Верификация Label 309 рассчитана на работу только с публичными данными, поэтому криптографические проверки не зависят от серверов CardanoWall. Что нужно каждой проверке:

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

Сеть обычно нужна только для одного — получить данные, которых у вас ещё нет, плюс подтвердить текущее состояние блокчейна. Сама же математика выполняется локально. (Полную модель верификации см. в статье как проверить запись Label 309.)

А как насчёт подтверждения в блокчейне, когда вы офлайн?

Метка времени подтверждения и статус его подтверждённости в блокчейне берутся из Cardano, и это факты, которые приложение считывает из сети, — оно их никогда не выдумывает.

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

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

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

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

Как работает офлайн-поиск входящих?

Ваши «Входящие» вычисляются локально из двух вещей: зеркальной копии записей и ваших разблокированных идентичностей. Шлюз намеренно не видит получателя — он понятия не имеет, какие запечатанные записи «ваши», — так что поиск вашей почты по замыслу выполняется локально.

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

Именно поэтому импорт старого Identity Seed корректно работает офлайн. Поскольку совпадение определяет только ключ получателя, приложение заново сканирует уже имеющуюся локальную зеркальную копию по этой идентичности и показывает более старые запечатанные записи, адресованные ей, — локальный проход, без повторной загрузки. (Ваша идентичность — это просто сид; см. ваша идентичность — это сид.)

Если зеркальная копия неполна, то и «Входящие» могут оказаться неполными. Когда сеть возвращается, приложение синхронизирует недостающие записи и продолжает поиск.

Почему бы не хранить всё только в облаке?

Потому что корнем доверия не должно быть облако. Размещённый сервис удобен — он может публиковать записи, отдавать ленту, обрабатывать расчёт стоимости и делать интерфейс простым. Но подтверждение должно пережить любую отдельную учётную запись сервиса, и весь смысл Label 309 в том, что для верификации нужна только публичная инфраструктура: метаданные транзакции, при необходимости байты содержимого и публичный обозреватель блокчейна Cardano. Локальная рабочая копия важных для вас записей — это практическое воплощение такой независимости.

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

Как команде использовать офлайн-подтверждения?

Заранее решите, что вам может понадобиться подтвердить без сети, — а затем синхронизируйте и закешируйте материал для верификации до того, как сеть пропадёт.

То, «что кешировать», определяется самой работой:

Юридической команде может понадобиться, чтобы зашифрованные пакеты доказательств были закешированы на одобренной машине.
Команде комплаенса может понадобиться, чтобы записи-подтверждения за каждый день и доказательства включения были доступны во время аудита.
Команде релизов или DevSecOps может понадобиться, чтобы подтверждения сборок и манифесты релизов были закешированы рядом с архивом релиза.
AI-команде может понадобиться, чтобы манифесты датасетов и обязательства по выводу модели были зеркально скопированы локально.

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

Какие риски у локального хранения подтверждений?

Офлайн-доступ перекладывает часть ответственности на устройство, и об этом стоит сказать прямо.

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

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

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

Что стоит сохранить для долгосрочного подтверждения?

Для подтверждений, которые важны на годы вперёд, храните больше, чем хеш транзакции. В зависимости от типа подтверждения это означает:

ссылку на транзакцию;
байты записи Label 309 (или проверенную выгрузку);
исходный файл или открытый текст;
шифротекст — для запечатанных записей;
Identity Seed или секрет получателя, нужный для расшифровывания;
список листьев Merkle или доказательства включения;
любые подписи или открытые ключи, нужные для атрибуции;
короткую заметку о том, как было создано подтверждение и к какому процессу оно относится.

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

Коротко

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

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

Что почитать дальше

CardanoWall Desktop — открытый десктоп-клиент, описанный в этой статье.
Как проверить запись Label 309 — модель верификации целиком.
Одна запись для тысяч файлов — пакетирование Merkle, целиком офлайн, кроме публикации.
Что подтверждение не доказывает — пределы зафиксированного во времени подтверждения существования.
Открытый код, CLI и SDK: github.com/cardanowall.