存在証明を作成したとき、ブロックチェーンには何が記録されるのか

CardanoWall で存在証明を作成したとき、Cardano 上に記録されるのは小さな証明レコードであって、ファイルそのものではありません。通常の存在証明（Proof of Existence）では、このレコードに、証明したいバイト列そのもののハッシュが含まれます。封印付き証明では、これに加えて暗号化エンベロープと、別の場所に保存された暗号文へのコンテンツアドレス指定リンクを持たせることもできます。平文のファイルを Cardano 上に置く必要は一切ありません。

この区別こそが核心です。公開された証明と、公開されたコンテンツは、同じものではありません。文書への永続的でタイムスタンプ付きのコミットメントを作成しながら、文書そのものは非公開のままにしておけます。

これが、CardanoWall が実装するオープン標準 Label 309 の背後にあるモデルです。この記事の残りでは、それぞれの種類の証明で何が公開されるのかを、正確に見ていきます。

ハッシュのみの証明では何が公開されるのか

ハッシュのみの証明で公開されるのは、レコードとハッシュだけです。それ以外には何もありません。

このレコードが示しているのは、実質的に次のことです。「誰かが、この Cardano のブロック時刻までに、まさにこのバイト列に対してコミットした」。ハッシュは、そのバイト列の暗号学的なフィンガープリントです。後から検証者は、元のファイルから同じハッシュを再計算し、それがチェーン上のものと一致するかを確認できます。

チェーンを読む人なら誰でも、次のものを見ることができます。

Cardano のトランザクション
メタデータラベル 309
Label 309 レコードのバイト列
コンテンツのハッシュ（1 つまたは複数）
ブロック時刻と確認のコンテキスト

見ることができないのは、ファイルそのものです。ただし、ご自分でそのファイルをどこかに別途公開した場合は別です。

だからこそ、存在証明は、非公開の文書、データセット、法務資料、コンプライアンスログ、社内の成果物に適しています。コンテンツを明らかにすることなく、公開されたタイムスタンプ付きのコミットメントが得られます。この考え方が初めての方は、存在証明とは何かで基礎を説明しています。

Cardano は私のファイルを保存するのか

いいえ。CardanoWall の通常の証明モデルでは保存しません。

Cardano が保存するのは、トランザクションとそのメタデータです。Label 309 では、そのメタデータが証明レコードを運び、レコードにはハッシュ、任意のストレージリンク、任意の署名、任意の Merkle ルート、任意の暗号化エンベロープデータを含めることができます。ファイルそのものが、平文のまま Cardano メタデータにアップロードされることは決してありません。

技術的にも明確な理由があります。Cardano は各メタデータ文字列を 64 バイトに制限しているため、レコード本体は、転送のためだけに小さなチャンクへ分割され、読み取られる前に再結合されます。ファイル全体が収まることはありません。ブロックチェーンは、非公開のファイルを投げ込む場所ではなく、後から他者が検証できるコミットメントをアンカーする場所です。仕組みの全体像は、Label 309 はどう動くのかをご覧ください。

ファイルを添付すると何が起きるのか

どの種類の証明を作成するかによって変わります。モードは 3 つあります。

ハッシュのみ。 CardanoWall はブラウザ内でファイルをハッシュ化し、レコードにはハッシュだけを公開します。元のファイルは手元に残り、デバイスから出ることはありません。

ストレージリンク付きの公開コンテンツ。 ファイルのバイト列をコンテンツアドレス指定ストレージに置き、Label 309 レコードがその保存先を参照します。コンテンツは公開され、リンクは、取得したバイト列をレコードに結びつけます。

封印付き。 ファイルはまず暗号化されます。暗号化されたペイロードは Arweave や IPFS のようなコンテンツアドレス指定ストレージを通じて保存され、レコードは暗号文を参照し、正しい鍵の保有者が復号するために必要なエンベロープデータを持ちます。

どのモードでも、証明はハッシュです。ストレージはバイト列の取得を助けるだけ、暗号化は誰が読めるかを制御するだけです。これは、ハッシュ、署名、封印、共有で説明している、ハッシュ・署名・封印・共有という同じ流れです。

封印付き証明では何が公開されるのか

封印付き証明とは、公開されたコミットメントを伴う非公開のコンテンツです。チェーンが「いつ」を証明し、暗号化が「誰が読めるか」を制御します。

公開レコードが明らかにするのは、意図的に狭く絞られた一連の事実です。

レコードが封印されていること（エンベロープが存在すること）
平文のハッシュ
ar://... や ipfs://... のようなコンテンツアドレス指定の暗号文リンク
暗号化エンベロープのヘッダー
受信者スロットに用いられた鍵カプセル化の系統（たとえば、古典的なものか、ハイブリッドのポスト量子的なものか）
暗号化された鍵スロットの数
レコードに含まれるあらゆる署名
トランザクションの時刻とオンチェーンメタデータ

公開レコードが明らかにしないのは、次のものです。

平文のファイル
復号されたメッセージ
読み取り可能な受信者の一覧
いずれかの受信者の秘密鍵
送信者の秘密鍵

暗号文は、ある狭い意味では公開です。誰でもストレージからダウンロードできます。しかし、一致する鍵がなければ、読み取り不能なままです。これが封印付きレコードの通常のパターンです。公開された証明、暗号化されたコンテンツ、そして受信者のデバイス上でローカルに行われる復号です。

受信アドレスはチェーン上に書き込まれるのか

いいえ。レコードのどこにも、読み取り可能な受信者ディレクトリはありません。

Label 309 の封印付きレコードでは、受信者には暗号化された鍵スロットを通じて到達します。受信者のクライアントは、公開された封印付きレコードをスキャンし、自分の秘密鍵で各スロットを静かに開こうと試みます。スロットが開くと、クライアントはペイロードを復号し、そのレコードを受信トレイに表示できます。チェーンが「受信者: Alice」と記したフィールドや、公開プロフィールを名指しするフィールドを運ぶことは決してありません。受信者の関係は、ローカルでの復号が成功することによって発見されるのであって、公開されるわけではありません。

この漏えいをさらに小さくするため、送信者は公開前に、安全な乱数生成器でスロットをシャッフルします。そのため、スロットの順序すら、誰が先頭に来るかについての手がかりを持ちません。チェーンが露出する、受信者に関わる唯一の事実は、スロットが「いくつ」あるかであって、それが「誰の」ものかは決して露出しません。

これが、この設計を大半のメッセージングシステムと分かつ点です。受信者が自分のレコードを見つけるために、サーバーが受信者の正体を知る必要はありません。封印付きレコードを受信する場合は、封印付きレコードの受信方法が受信トレイ側を説明しています。

「封印」は匿名を意味するのか

いいえ。封印とは、レコード形式が平文や読み取り可能な受信者の一覧を公開しないということです。これは確かに有用ですが、完全な匿名性と同じではありません。

周囲には、依然として情報を明らかにし得る数多くのシグナルが存在します。

トランザクションのタイミング
支払いの流れ
ゲートウェイでのアカウントの活動
ネットワークのメタデータ
ブラウザやデバイスのフィンガープリント
スロット数に繰り返し現れるパターン
送信者や受信者による運用上のミス

機微な業務では、この線引きを慎重に守ってください。Label 309 は、平文と受信者を公開レコードの外に保つことができます。しかし、周囲のネットワーク、支払い、デバイス、人的プロセスが生み出すあらゆる痕跡を消し去ることはできません。さらに、封印付きファイルを復号した受信者は、その後いつでも平文を漏えいさせることを選べます。コンテンツの機密性は、参加者の匿名性とは同じではありません。

レコードに署名すると何が公開されるのか

レコードに署名が含まれる場合、その署名は公開されます。そして、それぞれの署名の背後にある鍵も公開されます。

Label 309 の署名は、ある鍵がレコード本体を保証することを可能にします。これは、企業、クリエイター、システム、あるいはアイデンティティが、証明の裏付けとなりたいときに有用です。しかし署名は、公開鍵も露出させますし、署名の経路によっては、ウォレットに紐づく情報を露出させることもあります。公開された証明では、それがまさに望ましい場合もあります。機微な封印付きレコードでは、たいていそうではありません。

だからこそ、署名は任意であって、決して必須ではありません。ハッシュのみのレコードは、それ自体で存在を証明します。封印された、署名のないレコードは、いかなる送信者のアイデンティティもレコードに結びつけずに済みます。署名付きのレコードは、説明責任が目的であるときに、説明責任を加えます。正しい選択は、ワークフロー次第で完全に決まります。

はっきりと述べておくべき注意点が 1 つあります。検証された署名が証明するのは、ある鍵がレコード本体に署名したことです。同じ鍵がそのトランザクションを送信したことや、そのブロック時刻を選んだことを証明するわけではありません。誰でも、同一の本体を再公開できるからです。検証された署名は「この鍵によって署名された」と読むべきであって、「この鍵によってこの時刻に公開された」と読むべきではありません。

Merkle 証明では何が公開されるのか

Merkle 証明が公開するのは、単一のルートコミットメントだけであり、バッチについてそれ以外は何も公開しません。

何千ものハッシュを直接 Cardano メタデータに入れる代わりに、順序付けられた項目のリストから Merkle ツリーを構築し、単一の 32 バイトのルートだけを公開できます。ルートは公開され、項目の完全なリストはチェーン外に留まります。後から包含証明を保有する人は、ある特定の項目がコミットされたリストに含まれていたことを示すことができ、その証明は公開されたルートまで折りたたまれて戻ります。

これは、チェーンが大きなバッチに対して、その中のすべての項目を露出させることなくコミットすべきときに、適したツールです。

継続的インテグレーションとリリースの成果物
日次の監査ログ
AI のコンテンツ出力とデータセットマニフェスト
コンプライアンスの証拠
法的証拠のセット

ルートはリスト全体へのコミットメントを証明し、開示されていない項目は何も明らかにしません。トレードオフは運用上のものです。組織は、チェーン外のリーフリストと包含証明の材料を保全しなければなりません。ルートだけでは、それらを再現できないからです。このパターンは、何千ものファイルを 1 つのレコードでで詳しく扱っています。

CardanoWall は私の封印付きファイルを読めるのか

設計上、読めません。封印と復号は、デバイス上に留まる鍵で行われ、ゲートウェイは、封印されたコンテンツの復号に必要な秘密鍵を決して受け取らないように作られています。

ゲートウェイが見るのは、公開レコードのデータ、暗号文、見積もりと公開のメタデータ、アカウントの活動、ストレージの詳細です。証明を公開するために、ご自分の Identity Seed や、いずれかの受信者の秘密鍵は必要ありませんし、それらの秘密がゲートウェイに送られることは決してありません。

とはいえ、機密性はプロトコルの性質だけで決まるものではありません。侵害されたデバイス、悪意あるブラウザ拡張機能、フィッシングサイト、不注意なバックアップ、あるいはありふれた運用上のミスによって、秘密が露出することは依然としてあり得ます。レコード形式は、適切に封印されたファイルをゲートウェイにとって読み取り不能に保つことはできますが、ユーザーが自ら手放した鍵を守ることはできません。ですから、実践的な助言は変わりません。Identity Seed を保護し、機微なデータについては受信アドレスを別経路で検証し、信頼できるソフトウェアを使ってください。CardanoWall に見えるものが、この境界を詳しく説明しています。

ハッシュ以外は何も保存したくない場合は

その場合は、ハッシュのみの証明を作成してください。Label 309 はストレージリンクを一切必要としません。ハッシュのみのレコードは、それ自体で完全に有効です。元のファイルは手元で非公開のまま保ち、公開するのは証明レコードだけです。

これは、しばしば次のような場合に適したモデルです。

非公開の契約書
機密のデータセット
社内レポート
機微な法務資料
すでに非公開のリポジトリに存在するソース成果物
公開ストレージがリスクを増やすだけで何の利益も生まない、あらゆるもの

トレードオフは単純です。ハッシュは永遠に存在し続けますが、元のファイルを失えば、それに一致するバイト列をもはや作り出せなくなるかもしれません。そして、一致するバイト列のないハッシュは、ほとんど何も証明しません。ある文書についてそのリスクが問題になるなら、封印付き証明のほうが良い選択です。

暗号化したファイルを保全したい場合は

その場合は、封印付き証明を作成してください。封印付き証明は、元のバイト列が重要で、後から復元する必要が生じ得る場合のために作られています。ファイルは暗号化され、暗号文は保存または参照され、公開レコードは平文のハッシュにコミットします。

後から、一致する鍵を保有する人は、暗号文を復号し、その平文がオンチェーンのコミットメントと一致することを示せます。これは、長期的な証拠、機微なレコード、そして機密のまま保ちつつも消えてはならないデータに適しています。特定の相手と機密を保って共有する必要がある場合は、公開ファイルを使わない機密開示が実践的なガイドです。

要点

Cardano が保存するのは証明レコードであって、ファイルではありません。
レコードは、ハッシュ、署名、Merkle ルート、暗号化エンベロープのデータ、コンテンツアドレス指定リンクを運べます。
平文のファイルを Cardano 上に置く必要は決してありません。
封印付きファイルは、暗号文として Cardano の外に存在し、後からオンチェーンの平文のハッシュに照らして検証されます。
受信者は、チェーン上の受信者フィールドを読むことではなく、ローカルでの復号によって発見されます。

プライバシーモデルを一行で言えば、こうなります。公開されたコミットメント、非公開のコンテンツ、ローカルでの検証。

さらに読む

存在証明とは何かと Label 309 はどう動くのか — 証明レコードの背後にある基礎。
CardanoWall に見えるものと証明が証明しないこと — 正直に言える限界。
オープン標準は label309.org、ソースコードは github.com/cardanowall、そして CIP エディターによるレビュー中の Cardano メタデータ提案（PR #1205）。