すべての記事

約14分で読めます

CardanoWall Desktop:存在証明のためのローカルなメールクライアント

CardanoWall Desktop は Label 309 のためのオープンソースかつクロスプラットフォームなクライアントです。ローカルなアイデンティティ、オフラインファーストなレコードミラー、封印付き受信トレイ、送信済みレコードの追跡、そしてゲートウェイの自由な選択を備えています。その仕組みを解説します。

CardanoWall Desktop は Label 309 のためのオープンソースなデスクトップクライアントです。存在証明(Proof of Existence)のレコード、アイデンティティ、封印付きの受信トレイを、ブラウザのタブではなくご自分のマシン上に保持できます。使い心地はメールクライアントそのものです。自分宛ての封印付きレコードを集めた受信トレイ、公開したものをすべて見渡せる送信済みビュー、新しい証明を作るCompose フロー、公開されたオンチェーンのレコード全体を見渡すローカルな Explorer、受信アドレスを管理する Contacts、そしてローカルなアイデンティティ管理を備えています。

この記事では、その仕組みを解説します。ご自分の働き方に合うかどうかを判断する材料にしてください。

要点は「単なるデスクトップアプリ」ではありません。ブラウザでは完全には得られない 3 つの性質にこそ意味があります。オフラインファーストであること、ベンダーニュートラルであること、そして秘密鍵がデバイスから決して出ないように作られていることです。

デスクトップアプリはどんな課題を解決するのか

最も手軽に始められるのは Web アプリです。デスクトップアプリは、ローカルな所有を望む方のためのものです。

手早く証明を作る、レコードを公開する、アカウントベースのワークフローを動かす。こうした用途にはブラウザで十分です。一方で、それ以上を必要とする人や企業もいます。

  • ローカルで暗号化されたアイデンティティ保管庫
  • すでに同期したレコードへのオフラインアクセス
  • ローカルにキャッシュされた暗号化ファイル
  • サーバー側のルーティングではなく、ローカルでの復号によって見つかる非公開の受信トレイ
  • 公開レコード全体の検索可能なローカルミラー
  • ファイル全体をメモリに読み込むのではなくストリーミングする、大容量ファイル向けのワークフロー
  • 自前でホストするゲートウェイを指定できること
  • 特定のホスト型ベンダー 1 社を前提に組み込まれた仮定が少ないこと

CardanoWall Desktop は、こうした方々のために作られています。Label 309 のモデルをご自分のマシン上へ持ち込み、「オフライン」をエラーではなく通常の状態として扱います。

CardanoWall Desktop は Cardano ウォレットなのか

いいえ。ウォレットではありませんし、両者を取り違えることがないように設計されています。

ADA を保管することはありません。ウォレットのリカバリーフレーズを保持することもありません。Cardano トランザクションの構築や送信も行わず、チェーンやストレージの鍵も一切保持しません。

公開は、これまでどおり Label 309 ゲートウェイを通じて行われます。ゲートウェイは公開パイプライン全体を所有しています。価格設定、アップロード、Cardano トランザクションの構築と送信、確認、リオーグ処理、インデックス作成、そして残高の計上です。デスクトップアプリはクライアントです。Label 309 のアイデンティティをローカルに保持し、レコードを準備し、署名を選んだときには署名し、封印するペイロードを暗号化し、届いた封印付きレコードを復号し、証明を検証し、設定したゲートウェイと通信します。スクリプトやターミナルから同じ分離を望むなら、オープンソースのコマンドラインツールが同じ仕事をヘッドレスでこなします。

デスクトップアプリがオープンソースである理由

アイデンティティ、署名、暗号化されたファイル、長期にわたる証明を扱うソフトウェアは、検査できるべきだからです。

ツールがご自分の鍵と証拠に触れるのであれば、その動作を読めるべきですし、セキュリティチームが監査できるべきですし、開発者がその上に構築できるべきですし、運用者が自社のインフラを指定できるべきです。証明フォーマットはオープンであり、ゲートウェイもオープンであり、デスクトップクライアントもまたオープンです。Label 309 の他のコードと同じ Apache-2.0 ライセンスのもとにあります。標準は、その周りのツールがあってはじめて使えるものであり、それらのツールが利用者を囲い込まれた顧客に変えてしまってはなりません。

ここでいう「オフラインファースト」とは何か

オフラインファーストとは、ネットワークが利用できないときでもローカルアプリが役立ち続けることを意味します。表示される内容のよりどころとなるのは、ネットワークではなくローカルのデータベースだからです。

アプリはローカルな状態を保持します。同期したレコード、受信トレイの一致、送信済みレコード、連絡先、アイデンティティ、キャッシュされた暗号文、そして(オプトインした場合のみ)キャッシュされた復号済みファイルです。オフラインのときでも、次のことができます。

  • すでに同期したレコードを閲覧する
  • 受信トレイを読む
  • キャッシュされた封印付きファイルを復号する
  • キャッシュされたレコードを検証する
  • ローカルデータを検索する
  • あとで公開する証明を下書きする

オフラインだからといって、あらゆる操作が完了するわけではありません。新しい証明を公開するには、やはりゲートウェイとネットワーク接続が必要です。一度もキャッシュしていない暗号文を取得するには、やはりストレージへのアクセスが必要です。それでも、すでに同期したデータは Wi-Fi が切れたからといって消えることはありません。(オフラインであることそのものが目的となるケース、つまりエアギャップ環境でのハッシュ化と署名については、オフラインの証明をご覧ください。)

デスクトップの受信トレイはどう動くのか

受信トレイは、ご自分のアイデンティティが開ける封印付きレコードのローカルなビューです。そして、どのレコードがご自分宛てなのかをサーバーが知ることは決してありません。

ゲートウェイは、すべての Label 309 レコードの公開ストリームを提供します。デスクトップアプリは、そのストリームをローカルミラーへ同期します。ご自分のアイデンティティそれぞれについて、そのアイデンティティの受信鍵を使い、封印された鍵スロットをローカルで開こうと試みます。スロットが開けば、そのレコードはそのアイデンティティの受信トレイに現れます。

これは意図的に、サーバー側のメールボックスではありません。ゲートウェイのフィードは受信者を見分けられません。受信者ごとのフィールドを一切持たないため、封印付きレコードが誰宛てなのかを判別できないのです。クライアント側が試行復号によって、それを自力で見つけ出します。封印付き存在証明にローカルクライアントがこれほどよく合うのは、まさにこのためです。アイデンティティ鍵を保持するそのマシンこそが、受信トレイを組み立てられる唯一の場所だからです。

送信済みビューは何を追跡するのか

送信済みビューは、公開したレコードをそのライフサイクル全体にわたって追跡します。そして結果を信じるのではなく、検証します。

証明は、送信ボタンを押した瞬間に完了するわけではありません。証明はいくつかの段階を経て進みます。下書き、見積もり済み、アップロード中、公開中、送信済み、確認中、確認済み。あるいは、公開を完了できなければ失敗し、自動的に返金されます。デスクトップアプリは、そのライフサイクルをローカルで見える状態に保ちます。どのゲートウェイが使われたか、どのアイデンティティがレコードに署名したか、レコードが封印されていたか、どの受信者が選ばれたか、トランザクションがいつ確認されたか、そしてオンチェーンのレコードがアプリの準備したものと一致するとローカルの検証ツールが認めるかどうか。これらを表示できます。

その最後の点こそが重要です。「確認済み」は「ゲートウェイがそう言った」を意味すべきではありません。トランザクションを構築し送信するのはゲートウェイなので、それを鵜呑みにすべきではありません。バグのある、あるいは悪意あるゲートウェイは、別のトランザクションを報告したり、確認状況を偽って伝えたりしかねません。そこでアプリは、トランザクションハッシュが存在するようになったら、オンチェーンのレコードを取得し、公開した正確なレコードとバイト単位で比較してから、ようやく確認済みとして印を付けます。これは、自分自身の送信箱に対して適用したスタンドアロン検証です。

デスクトップではアイデンティティはどう保存されるのか

各アイデンティティはローカルで暗号化された保管庫に保存され、秘密のシードはアプリの中核にある Rust コアから決して出ません。

すべての Label 309 アイデンティティは、1 つの 32 バイトの Identity Seed(アイデンティティの種)に根ざしています。アプリはそのシードから、アイデンティティの署名鍵と受信鍵を導出します。シードそのものはローカルのコアの内側にとどまります。インターフェースを描画する webview に送られることはなく、いかなるゲートウェイにも送られることはありません。インターフェースが目にするのは、常に公開された射影だけです。ラベル、フィンガープリント、公開鍵、受信アドレス、そして状態です。保管庫がアンロックされている間、シードはゼロ化されるメモリ上に存在し、アプリをロックしたときや、アイドル状態で自動ロックされたときに消去されます。

この分離こそが設計のすべてです。シードは持ち運び可能なバックアップであり、守る価値のあるものなので、最重要の財産として扱われます。アカウントでもパスワードでもなくシードこそが本当のアイデンティティである理由については、あなたのアイデンティティはシードであるを、そしてそれをデバイス上にとどめる原則については、なぜ鍵はデバイスから出ないのかをご覧ください。

正直に言えば、1 つの限界があります。秘密をローカルのコアに保持することは、悪意ある、あるいはバグのあるインターフェースに対しても、盗まれてロックされた保管庫ファイルに対しても、防御になります。しかし、完全に侵害されたオペレーティングシステムを打ち負かすことはできません。アプリがアンロックされている間は、同じマシン上のマルウェアが原理上はメモリ内の秘密を読めてしまう可能性があります。短いアンロック時間、自動ロック、最小限の依存関係はその露出を減らしますが、消し去ることはできません。これは、あらゆるデスクトップウォレットが背負っているのと同じ注意点です。

自分のゲートウェイを使えるのか

はい。そしてそれこそが、デスクトップアプリが存在する主な理由の 1 つです。

互換性のある任意の Label 309 ゲートウェイで動作します。手軽さのために公式の CardanoWall ゲートウェイを指定することも、自社が運用する自前ホストのゲートウェイを指定することも、誰か別のプロダクトの背後にあるゲートウェイを指定することもできます。公式のものはせいぜいワンクリックの便利な入口にすぎず、選んでもいないのに既定になることは決してありません。ゲートウェイのベース URL とアカウントキーを入力すると、アプリはそのエンドポイントを調べ、頼りにする前に、それが標準に準拠していることを確認します。

役割分担は明快です。ゲートウェイは公開パイプラインを所有し、デスクトップはローカルクライアントの体験を所有します。その分離こそが、ロックインを防ぎます。ご自分のローカルアプリ、ローカルのアイデンティティ、ローカルのキャッシュ、そして標準準拠のレコードは、たった 1 つのホスト型インターフェースに依存すべきではないのです。

ゲートウェイには何が見え、何が決して見えないのか

ゲートウェイには、公開しサービスを運用するために必要なものが見えます。そして、封印付きファイルを読んだり、本人になりすましたりできるようなものは何も見えません。

ゲートウェイには、アカウントの資格情報、価格の見積もり、アップロード、暗号文、残高、トランザクションの状況、公開レコードのバイト列、そして運用上のメタデータが見える場合があります。しかし、Identity Seed は見えず、受信者の秘密鍵も見えず、封印付きファイルを復号することもできません。デスクトップアプリは、あらゆる秘密をローカルで準備し使用します。ゲートウェイは、標準準拠のレコードを公開し、公開フィードを提供するだけです。

これは、ゲートウェイが決して不正を働けないという意味ではありません。ゲートウェイは、遅延させたり、失敗したり、レコードを差し止めたり、状況を誤って報告したりしうるのです。だからこそ検証が重要になります。有効な証明は、公開されたオンチェーンのレコードと公開された Cardano エクスプローラーから検証できるのであって、ゲートウェイのインターフェースがそう言うから信じるのではありません。

オフラインのとき、ファイルに対して何ができるのか

それは、何を同期しキャッシュしてあるかによります。そしてアプリは、どのファイルなら手元に置いても安全かについて正直です。

暗号文はすでに暗号化されているため、自由にキャッシュできます。すると、受け取ったファイルを再び開くのは瞬時で、オフラインでも動作します。復号済みファイルはより慎重を要するため、復号済みファイルのキャッシュはオプトインであり、既定では無効で、それ自体も暗号化されています。既定の動作は、暗号文を保持し、必要に応じてその都度メモリ内で復号することです。

役立つ考え方の枠組みを示します。

  • 公開レコードのメタデータはローカルにミラーできます
  • 暗号文はオフラインアクセスのためにキャッシュできます
  • 復号済みファイルは慎重に扱われ、明示的に保存した場所にのみディスクへ書き込まれます
  • Identity Seed は保管庫の中で保護され続けます
  • 検証は、キャッシュされたレコードとファイルに対してローカルで実行されます

これにより、復号済みファイルがリスクゼロであるかのように装うことなく、オフラインで作業する実際の利点が得られます。そして、復号済みファイルはやはりただのファイルにすぎません。いったん保存すれば、それを渡した相手は誰でも読めます。封印付き証明はコンテンツを鍵の保有者だけに秘匿しますが、受信者を信頼に足る相手にするわけではありません。

デスクトップアプリは誰のためのものか

ブラウザのタブが適切な道具ではなくなるほど、日常的に証明を扱う人や組織のためのものです。

よく合うのは、次のような方々です。

  • 封印付きの証拠を受け取る法務・コンプライアンスの各チーム
  • 機密のレコードを扱うジャーナリストとその情報源
  • 反復的なコンプライアンス証明を公開する企業
  • 自動化の中で Label 309 を使う開発者やプラットフォームチーム
  • データセットと出力のコミットメントを保全する AI チーム
  • オリジナルの作品の署名付き証明を保持するクリエイター
  • 証拠パッケージへのローカルアクセスを必要とする監査人
  • 自前ホストやベンダーニュートラルなインフラを好むすべての人

たまにしか証明を公開しないのであれば、最もシンプルな道は Web アプリのままですし、オープンソースのコマンドラインツールを使えば、今日この時点ですでに、ウェブサイトなしで作業できます。デスクトップアプリは、継続的な作業のためのものです。

得られるもの

これはローカルファーストなプロダクトであり、軽量なおもちゃではなく、本格的な証拠ソフトウェアのように振る舞います。得られるものは次のとおりです。

  • うっかりアイデンティティを失わないための、明確なアイデンティティのバックアップ案内
  • ウォレットのシードとの混同のなさ
  • 透明性のある検証状態
  • 読みやすい確認状況
  • 帯域外で慎重に行われる受信アドレスの取り扱い
  • ご自分のレコードと開いたファイルを横断するローカル検索
  • 安全なインラインファイルプレビュー
  • 複数のアイデンティティを 1 か所で
  • 照合可能なフィンガープリント付きの連絡先
  • ゲートウェイの自由な選択
  • 静かな失敗ではなく、正直なエラー状態

標準は証明のモデルを与えてくれます。デスクトップアプリは、その周りに整った作業環境を与えてくれます。オープンソースのコードからダウンロードできます。

短くまとめると

CardanoWall Desktop は、Label 309 のためのローカルクライアントです。公開レコード全体を同期し、アイデンティティをローカルに保持し、封印付きの受信トレイ項目をローカルな試行復号によって見つけ出し、送信した証明を(そしてオンチェーンでそれらを検証しながら)追跡し、すでに同期したデータでオフライン動作し、互換性のある任意のゲートウェイに接続します。

Web アプリは手軽さを与えてくれます。デスクトップアプリはローカルなコントロールを与えてくれます。

さらに読む

cardanowalldesktoplabel-309