CardanoWall の証明はオフラインでも使えるのか

はい。すでにデバイス上にあるものなら使えます。Label 309 レコード、そのコンテンツまたは暗号文、そしてそれを開くための鍵が一度同期されれば、CardanoWall Desktop はネットワーク接続なしで閲覧・検索・復号・検証できます。できないのは、一度も見ていないデータをでっち上げることです。同期したことのないトランザクションや、ダウンロードしたことのない暗号文は扱えません。

CardanoWall Desktop はオフライン優先で動作します。目の前の画面にとって信頼できる唯一の情報源はローカルデータベースであり、ネットワークはそのデータベースを背後で埋めていく同期役にすぎません。ですから「オフライン」はエラーではなく通常モードです。ローカルマシンは、すでに手元に取り込んだ証明世界の一部の作業コピーになります。

その作業コピーこそが、現場で証明を役立てるための鍵です。出張中、監査、法務レビュー、インシデント対応など、接続が不安定なあらゆる場面で力を発揮します。タブがサーバーに到達できないというだけで、証明が読めなくなってはいけません。CardanoWall Desktop はオープンソースです。オープンソースの Rust SDK の上に Rust と Tauri で構築されており、コードは github.com/cardanowall にあります。ですから、その動作を鵜呑みにするのではなく、実際にどう振る舞うかを正確に読み解けます。

同期済みの証明でオフラインに何ができるのか

データがすでにローカルにある限り、かなり多くのことができます。ローカルにあれば、CardanoWall Desktop は次のことを可能にします。

• 同期済みの公開 Label 309 レコードの閲覧
• コンテンツハッシュによる検索を含む、ローカルレコードミラーの検索
• 試行復号（trial-decrypt）によってすでに発見された受信トレイレコードの表示
• キャッシュ済み暗号文のオープン
• ローカルの鍵による封印付きファイルの復号
• ローカルファイルに対するハッシュの検証
• キャッシュ済みレコードの構造チェック
• 送信済みレコード履歴の確認
• あとで公開するための下書きの準備

これらはキャッシュされたスクリーンショットではなく、本物の暗号処理です。ハッシュチェック、署名チェック、試行復号は、いずれもアプリの Rust コア内で、すでにディスク上にあるバイト列に対してローカルに実行されます。

オフラインでできないことは何か

オフラインモードには明確な限界があり、その限界がどこにあるかについて正直です。アプリは、一度も持ったことのないデータを作り出すことはできません。

• トランザクションが一度も同期されていなければ、ネットワークか、そのメタデータの別のローカルコピーがない限り、アプリはそれが存在することを知りようがありません。
• 暗号文が一度もダウンロードされていなければ、アプリはオフラインでそれを復号できません。
• レコードがストレージ URI を指していて、そのバイト列がキャッシュされていなければ、アプリは接続なしにそれを取得できません。
• 新しい証明を公開したい場合、アプリにはゲートウェイとネットワークが必要です。公開の見積もり、アップロード、Cardano トランザクションの送信、そしてその確認を行わなければなりません。（公開は常にゲートウェイを通して実行されます。詳しくは なぜ公開に料金がかかるのか をご覧ください。）

オフライン優先とは、アプリが欠けているデータを補えるという主張ではありません。データが一度ローカルになれば、アプリがそれを第一級のものとして扱うという主張です。

アプリは何をキャッシュし、各レイヤーの機密性はどの程度か

機密性の低い順に、4 つのレイヤーがあります。

公開レコードメタデータ。 デスクトップは、設定したゲートウェイから取得した Label 309 レコード（封印付きと公開の両方）の完全なローカルミラーを保持します。各レコードは小さく（単一のトランザクションのメタデータで、Cardano の約 16 KB のメタデータ上限を大きく下回ります）、グローバルなセット全体でも、何年も使い込んだあとで数百メガバイトの範囲に収まります。このミラーは、検索、受信トレイ発見、送信済みレコードの追跡、そしてオフライン検査の土台です。チェーン上ですでに公開されているものしか含まないため、設計上、暗号化せずに保存されます。公開データのコピーを暗号化しても、得るものは何もないからです。

暗号文。 封印付きレコードは、コンテンツアドレス指定ストレージ（ar:// や ipfs://）を通じて暗号化されたペイロードを参照します。その暗号文のキャッシュは安全です。すでに暗号化されており、対応する鍵を持つ者だけが開けるからです。デスクトップはこれをキャッシュするので、受信したファイルの再オープンが瞬時に、かつオフラインでも行えます。

復号済みコンテンツ。 これが機密性の高いレイヤーであり、アプリは慎重に扱います。デフォルトでは必要に応じてメモリ上に復号し、平文をディスクに書き込むことは決してありません。再展開なしで即座にプレビューしたいユーザーのために、別途暗号化された復号済みファイルのキャッシュもありますが、これはデフォルトでオフです。平文が通常の場所に書き込まれるのは、明示的に「保存」を選んだときだけです。復号済みファイルがいつ、どこに、どう保護されて保持されるのかを、常に把握できるようになっています。

アイデンティティ素材。 Identity Seed（アイデンティティの種）は暗号化された保管庫に収められ、ローカルで解錠されます。該当するアイデンティティが解錠されていなくても、封印付きレコードは公開レコードとしてミラーに表示されます。ただ、そのコンテンツを開けないだけです。Identity Seed そのものはデバイスを離れることはなく、いかなるゲートウェイにも届きません。（その境界がなぜ重要かについては、鍵がデバイスを離れない理由 をご覧ください。）

オフラインで証明を検証できるのか

はい。チェックに必要な入力がそろっていれば検証できます。Label 309 の検証は公開データだけで実行できるよう設計されており、暗号的なチェックは CardanoWall のサーバーに一切依存しません。各チェックに必要なものは次のとおりです。

• ハッシュ証明 には、レコードと元のバイト列が必要です。検証ツールはそのバイト列からハッシュを再計算し、レコードにコミットされたハッシュと比較します。完全にオフラインです。
• 署名付き証明 には、レコードとそこに埋め込まれた署名が必要です。署名鍵はレコードの署名構造に含まれるか、そこから解決されるため、レコードがローカルにあれば署名検証はオフラインで実行できます。
• 封印付き証明 には、レコード、暗号文、そしてそれを開く受信者鍵（またはパスフレーズ）が必要です。これらがローカルにあれば、アプリは復号し、平文のハッシュを再計算し、それをレコードのコミットメントと照合します。これが、暗号化されたバイト列をタイムスタンプ付きの主張に結びつけるステップです。
• Merkle 証明 には、レコードに含まれるルートと、包含証明（またはそれを再構築するためのリーフリスト）が必要です。あとはゲートウェイを介さずに包含チェックがオフラインで実行されます。Merkle ツリーの構築と包含の検証は純粋な計算です。詳しくは 何千ものファイルを 1 つのレコードで をご覧ください。

通常ネットワークが必要になるのは、まだ持っていないデータを取得することと、現在のチェーン状態を確認することだけです。計算そのものはローカルで実行されます。（検証モデルの全体像については、Label 309 レコードを検証する方法 をご覧ください。）

オフラインのときブロックチェーンの確認はどうなるのか

証明のタイムスタンプと確認ステータスは Cardano に由来します。これらはアプリがチェーンから読み取る事実であって、アプリが勝手に作り出すことは決してありません。

アプリがすでにトランザクションとその確認深度を同期していれば、そのキャッシュ状態をオフラインで表示できます。オフラインでできないのは、新しい確認、チェーンの再編成、その他の更新されたコンテキストを知ることです。それには Cardano エクスプローラーへの問い合わせが必要だからです。

そのため、慎重なクライアントはこれらの状態を区別して扱います。

• キャッシュ済みでローカル検証済みのレコードデータ
• 各項目が最後に同期された時刻
• 最後の同期時点での確認深度
• まだ保留中、または確認しきい値を下回っているレコード
• オンラインでの再チェックが必要なレコード

オフライン表示は鮮度について正直であるべきです。先週の確認深度を、あたかも最新であるかのように見せてはいけません。

オフラインでの受信トレイ発見はどう機能するのか

受信トレイは、レコードミラーと解錠済みのアイデンティティという 2 つのものからローカルに計算されます。ゲートウェイはあえて受信者ブラインドになっており、どの封印付きレコードが「自分のもの」かを一切知りません。ですから、自分宛てのメールを見つけるのは設計上ローカルの仕事です。

アプリが封印付きレコードを同期していれば、デバイス上で、ご自分のアイデンティティに対してそれらを試行復号します。封印された各スロットについて復号を試み、手元の鍵で開けたものが自分宛てのメッセージです。誰であるかをサーバーに尋ねることはありません。

これは、古い Identity Seed をインポートしてもオフラインできれいに動く理由でもあります。一致を判定するのは受信者鍵だけなので、アプリはそのアイデンティティについてすでに存在するローカルミラーを再スキャンし、それ宛てだった古い封印付きレコードを浮かび上がらせます。再ダウンロードのないローカルパスです。（アイデンティティとは、そのシード（= Identity Seed）にほかなりません。詳しくは あなたのアイデンティティはシードである をご覧ください。）

ミラーが不完全なら、受信トレイも不完全になり得ます。ネットワークが復帰すると、アプリは欠けているレコードを同期し、発見を続けます。

すべてをクラウドだけに置かないのはなぜか

クラウドが信頼の根であってはならないからです。ホスティングされたサービスは便利です。レコードを公開し、フィードを配信し、料金を処理し、インターフェースを使いやすくできます。しかし証明は、どの 1 つのサービスアカウントよりも長く生き残るべきです。そして Label 309 の核心は、検証に公開インフラだけ、つまりトランザクションメタデータ、必要に応じてコンテンツバイト、そして公開された Cardano エクスプローラーだけがあれば足りるという点にあります。必要とするレコードのローカルな作業コピーは、その独立性を実用的に体現したものです。

そのローカルコピーは、1 回の Web セッションでは脆すぎるまさにその場面で真価を発揮します。監査、インシデント対応、リーガルホールド、証拠レビュー、ジャーナリズム、研究アーカイブ、規制下のワークフロー、そして長期保存です。

チームはオフライン証明をどう使うべきか

ネットワークなしで何を証明する必要が生じうるかを、あらかじめ決めておきましょう。そして、ネットワークが失われる前に検証素材を同期し、キャッシュしておきましょう。

「何をキャッシュするか」のかたちは、業務に従って決まります。

• 法務チームは、承認済みのマシンに暗号化された証拠パッケージをキャッシュしておきたいかもしれません。
• コンプライアンスチームは、監査の間に毎日の証明レコードと包含証明を利用できるようにしておきたいかもしれません。
• リリースチームや DevSecOps チームは、ビルド証明とリリースマニフェストをリリースアーカイブと一緒にキャッシュしておきたいかもしれません。
• AI チームは、データセットマニフェストとモデル出力のコミットメントをローカルにミラーしておきたいかもしれません。

ルールはシンプルです。オフラインで証明する必要が生じうるなら、接続が消える前にそれを同期し、それを証明する素材をキャッシュしておくことです。封印付きコンテンツについては、関連する Identity Seed がバックアップされ、ポリシーに従って適切な人やデバイスが利用できることもあわせて確認してください。それがなければ、暗号文は閉じたままです。

証明をローカルに保持するリスクは何か

オフラインアクセスは一部の責任をデバイス側に移します。その点を明確にしておく価値があります。

ローカルストレージのリスクがあります。デバイスが盗まれれば、そのキャッシュが問題になります。キャッシュされた暗号文は暗号化されており、鍵なしには開けません。しかし、保持を選んだ復号済みファイルはどれも機密であり、アイデンティティ保管庫は保護されなければなりません。オペレーティングシステム、ディスク暗号化、ユーザーアカウント、パスフレーズ、そして一般的なデバイスセキュリティのすべてが、信頼を支える要素の一部になります。CardanoWall Desktop は、暗号化された保管庫、自動ロック、そしてメモリ上の鍵のベストエフォートなゼロ化によって露出を減らしますが、完全に侵害され解錠状態のマシンを守ることはできません。そして、それをはっきりと明言しています。

鮮度のリスクもあります。キャッシュされた証明は最後の同期時点では有効ですが、アプリは再接続するまで現在のチェーン状態を知ることができません。

優れたソフトウェアは、これらの境界を見えるようにします。最後の同期時刻を表示し、キャッシュ検証と新しいオンラインチェックを区別し、復号した平文を安全でない場所に黙って書き込むことを避けます。

長期の証明のために何を残すべきか

何年にもわたって重要な証明には、トランザクションハッシュ以上のものを残しましょう。証明の種類に応じて、それは次のものを意味します。

• トランザクション参照
• Label 309 レコードのバイト列（または検証済みのエクスポート）
• 元のファイルまたは平文
• 封印付きレコードの場合は暗号文
• 復号に必要な Identity Seed または受信者の秘密
• Merkle のリーフリストまたは包含証明
• 帰属に必要な署名または公開鍵
• 証明がどう作られ、どのプロセスに属するかを記した短いメモ

ブロックチェーンが提供するのは公開のアンカー、つまりこれらのバイト列が公開のブロック時刻までに存在したという事実です。手元のローカルアーカイブは、そのアンカーをあとで役立てるためのコンテキストを保ちます。（そして、そのアンカーが何を主張し、何を主張しないかを忘れないでください。証明が証明しないこと をご覧ください。）

手短に言えば

オフライン証明は魔法ではなく、準備です。レコード、コンテンツ、暗号文、鍵、そして包含証明がローカルにあれば、暗号的なチェックはすべてローカルで実行されます。何かが一度も同期もキャッシュもされていなければ、アプリはそれを取得するためにネットワークを必要とします。そして、ふりをするのではなく、そのことをきちんと知らせます。

CardanoWall Desktop は、そのローカルな作業コピーを当たり前のものにします。レコードを同期し、封印付きの受信トレイ項目をデバイス上で発見し、暗号化されたファイルをキャッシュし、証明を検証し、ネットワークが失われても同期済みの証拠を役立つ状態に保ちます。

さらに読む

• CardanoWall Desktop — この記事が説明するオープンソースのデスクトップクライアント。
• Label 309 レコードを検証する方法 — 検証モデルの全体像。
• 何千ものファイルを 1 つのレコードで — 公開を除いてすべてオフラインの Merkle バッチ処理。
• 証明が証明しないこと — タイムスタンプ付き存在証明の限界。
• オープンソースのコード、CLI、SDK は github.com/cardanowall にあります。