← すべての記事

約13分で読めます

存在証明が証明しないこと

存在証明は、ある特定のバイト列が公開時刻までに存在していたことを示します。所有権・真実性・著作者・先行性・適法性・証拠能力までは、それ単独では証明しません。

存在証明（Proof of Existence）が証明するのは、ただ一つの限定された事実です。すなわち、この特定のバイト列が、ある公開時刻までに存在していたということです。これは本当に役立つ事実であり、同時に主張のすべてでもあります。

有効な証明があっても、そのファイルが真実であること、オリジナルであること、公開者に所有されていること、法的に利用できること、完全であること、あるいは法廷で証拠能力を持つことが自動的に示されるわけではありません。これらはそれぞれ、固有の裏付けを必要とする別個の主張です。証明をうまく使い、過剰な主張を避けるための最短の道は、その保証がどこで止まるのかを正確に理解することです。

この記事では、タイムスタンプがカバーすると思われがちな主張を一つずつ取り上げ、何を証明し何を証明しないのかをはっきりと述べます。そのうえで、もっと多くが必要なときに欠けている層をどう追加するかを示します。

存在証明が実際に証明するものとは

それは、ある時点に対するバイトレベルのコミットメントです。

誰かが、ファイル・メッセージ・データセット・画像・動画・アーカイブ・マニフェストを取り、その暗号学的ハッシュを計算します。そのハッシュは、公開されたタイムスタンプ付きレコードに格納されます。後日、元のバイト列を持つ人がハッシュを再計算し、レコードと照合します。両者が一致すれば、検証者は次のことを確信を持って言えます。

この特定のバイト列は、公開レコードの時刻までに存在していました。

CardanoWall とオープンな Label 309 標準では、この公開レコードはメタデータラベル 309 の下で公開された Cardano のトランザクションメタデータです。これを確認するには、検証ツールが公開された Cardano のエクスプローラーからトランザクションを読み取り、Label 309 レコードを再構成し、その構造を検証して、ハッシュ（バッチ処理されたレコードであれば Merkle 包含証明）を照合します。この確認に CardanoWall のサーバー・ドメイン・アカウントは一切関与しません。証明は公開チェーンだけで成立します。

このコミットメントが土台です。そのあとに続くものは、すべて別の問いです。

証明はファイルが真実であることを証明するのか

いいえ。偽の記述も、真実の記述と同じくらい簡単にタイムスタンプを付与できます。捏造された請求書、誤った報告、加工された画像。これらはどれも何らかのハッシュ値になり、どれもチェーン上に記録できます。

存在証明は内容を判定しません。特定の内容がある時刻までに存在していたことを証明するのであって、その内容が正しいことを証明するわけではありません。

それでも、価値は大きいものです。報告が後で訂正された場合、元の報告の証明は、訂正前に何が存在していたかを示します。画像に争いが生じた場合、証明は、特定のファイルが争いの始まる前に存在していたことを示します。しかし、ファイルの内側にある主張が正確かどうかは、まったく別のところから来ます。すなわち、周辺の証拠、レビューのプロセス、データの出所、証人、そして文脈です。

証明はいつとどのバイト列かを確定します。真か偽かを決めることは決してありません。

証明は所有権を証明するのか

いいえ。ファイルが公開されていれば、誰でもハッシュ化できます。公開された PDF・写真・動画・ソースファイル・データセットにタイムスタンプを付与しても、それで所有者になるわけではありません。記録されるのは、その時刻までにそのバイト列を保持していたという事実だけです。

タイムスタンプは、他の事実と並んだとき、所有権をめぐる説明を支える場合があります。

  • 下書きと編集履歴
  • 署名付きレコード
  • 元のソースファイル
  • 契約書とライセンス
  • 雇用または委託の記録
  • リポジトリの履歴
  • 共同制作者とのやり取り

証明は、時間に関する証拠です。権利証ではなく、排他的な権利を確立するものでもありません。

証明は誰がファイルを作ったかを証明するのか

それ単独ではできません。ハッシュのみの証明は、バイト列が存在していたことを述べますが、誰がそれを作ったかについては何も語りません。二人が同じファイルを持っていれば、どちらでも同じハッシュを公開できます。

Label 309 レコードには、任意で署名を載せることができます。署名付きレコードは、特定の暗号鍵がレコード本体に署名したことを証明します。これは、証明をトランザクションをたまたま送信した人ではなく鍵に結びつけるため、ただのハッシュよりも実質的に強力です。署名は標準のなかで常に任意です。発行者に依存しない立場を保ちたい公開者は、単に署名を省けばよいのです。

署名がある場合でも、言い回しが重要になります。署名は、その鍵がレコードに署名したことを証明します。それ単独では、その鍵の背後にいる現実の人物までは証明しません。その結びつきは、鍵がどのように確立されたかから生まれます。すなわち、オンボーディング、公開された公開鍵、組織のポリシー、契約、デバイスの管理、あるいは証明そのものの外にある別のプロセスです。

著作者も併せ持つ証明が欲しいのであれば、意図して署名し、署名鍵を慎重に管理してください。各ステップをいつ追加する価値があるかは、ハッシュ化・署名・封印・共有 の解説で扱っています。

証明は公開者が最初だったことを証明するのか

たいていの場合、それ単独ではできません。証明は、公開者がある時刻までにバイト列を保持していたことを示せます。しかし、それより前に誰も保持していなかったことは示せません。

これが最も重要になるのは、AI の学習データ、データセット、創作物、営業秘密です。ある企業が今日データセットのマニフェストにタイムスタンプを付与すれば、そのマニフェストが今日存在していたという強力な証拠を得られます。しかし別の当事者がより古い証明、リポジトリの履歴、署名付きレコードを示せば、時系列はその当事者の側に傾きます。

実践的な教訓は、早めに、そして一貫して公開することです。後からの証明にも依然として価値はありますが、より早い公開コミットメントが常により強いものです。早くチェーン上に記録するほど、自分の時系列はくつがえしにくくなります。

証明はファイルが一度も変更されていないことを証明するのか

証明が示すのは、もっと正確なことです。すなわち、いま手元にあるファイルが、コミットされたバイト列と一致するということです。

どこかにあるコピーが一度も改変されていないことまでは証明しません。手元のディスクを保護するわけでもなく、誰かがファイルの別バージョンを編集することを止めるわけでもありません。証明が答える検証の問いは、限定された具体的なものです。

このファイルは、公開レコードのなかのハッシュと一致するか。

一致すれば、目の前のファイルはコミットされた特定のバイト列そのものです。一致しなければ、ファイルが変わったか、誤ったファイルが渡されたか、誤ったハッシュが照合されたか、あるいはレコードが別のバイト列に属しているか、のいずれかです。不一致だけでは、そのうちのどれなのかはわかりません。

後で防御が必要になりそうなものについては、三つを一緒に保管してください。すなわち、元のファイル、トランザクション参照、そしてマニフェストまたは Merkle 包含証明です。元のファイル自体が失われるおそれがあるなら、それはまさに封印付き証明の出番です。

証明はファイルを保全してくれるのか

ハッシュのみの証明は保全しません。ハッシュだけを公開し、後で元のバイト列を失った場合、何らかのバイト列が存在していたという証拠は依然として残るかもしれません。しかし、その列が何であったかを示せなくなるおそれがあります。

だからこそ Label 309 は封印付きレコードに対応しています。封印付き証明は、平文のハッシュにコミットしつつ、暗号化された暗号文をコンテンツアドレス指定の保存先に格納します。保存先は ar://（Arweave）や ipfs://（IPFS）の URI で指定されます。適切な鍵を持つ人は、後で暗号文を取得し、復号し、平文のハッシュを再計算して、オンチェーンのコミットメントと一致することを確認できます。こうしてバイト列と、それを時刻に結びつける証明の両方を回復できます。

ファイルを自分で保管し続けるなら、ハッシュのみで十分です。回復や、他者への引き渡しが計画の一部なら、封印のほうが優れた選択です。

証明は適法性やコンプライアンスを証明するのか

いいえ。企業は、不適切に収集したデータにタイムスタンプを付与できます。クリエイターは、配布する権利のないコンテンツにタイムスタンプを付与できます。チームは、不完全なコンプライアンスログにタイムスタンプを付与できます。ベンダーは、まだ脆弱性を抱えたまま出荷されるソフトウェアのリリースマニフェストにタイムスタンプを付与できます。

存在証明は、レコードを改ざんが検知可能で時刻に固定された状態にすることで、コンプライアンスの取り組みを支える場合があります。しかし、コンプライアンスプログラムそのものの代わりにはなりません。

本当のコンプライアンスは、ポリシー、統制、適法なデータ収集、アクセス記録、保持ルール、レビュー、承認、そして場合によっては外部監査から生まれます。証明は、何がいつ存在したかを示す助けになります。基礎となるプロセスが正しかったことを証明するわけではありません。監査証跡をチェーン上に記録するなら、ベンダーを信頼しないコンプライアンスログ がまさにこの境界を扱っています。

証明は証拠保全の連鎖（chain of custody）を確立するのか

いいえ。証拠保全の連鎖はプロセスの物語です。誰が物を収集し、どこに保管され、誰がアクセスし、どう移動し、どのツールが触れ、その過程で改ざんを防ぐためにどのような統制があったか、というものです。

Label 309 の証明は、その物語の一片になり得ます。ファイル、エクスポート、ログ、証拠マニフェストが公開時刻までに存在し、後でも一致することを示せます。しかし、すべての保管者を挙げたり、すべての取り扱い手順を説明したりはできません。それらの事実自体がどこか他の場所で記録され、理想的にはコミットされていない限りは無理です。

証拠ワークフローでのパターンは、マニフェストにタイムスタンプを付与し、証明が指し示す周辺のプロセス記録を併せて保管することです。

証明はプライバシーを保証するのか

いいえ。そして、その限界は具体的に述べておく価値があります。

ハッシュのみのレコードは、通常の条件下では元のファイルを明らかにしません。それでも、誰かが何かをコミットしたという事実を、ある時刻に開示してしまいます。さらに、ファイルがエントロピーの低いものや推測可能なものであれば、攻撃者は候補となるバイト列をハッシュ化し、一致が現れるまで一つずつレコードと照合できます。

封印付きレコードはさらに踏み込みます。平文が平文のままオンチェーンに載ることはありません。載るのはそのハッシュと、受信者を識別できない封印エンベロープだけで、暗号文はオフチェーンに保たれます。加えて Label 309 は、受信者の公開鍵がレコードに一切現れないよう意図的に設計されています。しかし、プライバシーはレコード形式よりも大きな問題です。タイミング、手数料の支払い、ゲートウェイのログ、IP アドレス、ブラウザの挙動、ストレージへのアクセス、暗号化されたペイロードの外にあるファイル名、そして日常的な運用ミス。これらはいずれも、暗号が決して触れない情報を漏らし得ます。

機微なワークフローには、暗号化だけでなく、証明をめぐる運用上のセキュリティが必要です。何も公開せずに特定の相手だけに開示することが目的なら、公開ファイルなしの秘密開示 がそのアプローチを扱っています。

証明は匿名性を保証するのか

いいえ。署名のない封印付き Label 309 レコードは、送信者のアイデンティティや読み取り可能な受信者リストを証明レコード自体に載せずに済みます。ラップされた鍵を保持するスロットが明かすのは受信者が何人いるかであって、誰かは決して明かしません。これは実在する有用な性質です。しかし、それで周辺の公開プロセスまで匿名になるわけではありません。

Cardano のトランザクションには依然として入力があり、手数料を支払います。ホスト型のゲートウェイは、アカウント・支払い・ネットワーク・タイミングの詳細を見るかもしれません。ストレージから暗号文を取得すれば、痕跡が残り得ます。利用者がアドレスを再利用したり、どこか別の場所で文脈を明かしてしまったりすることもあります。

ですから、正直に言える主張は限定的です。すなわち、レコード形式は読み取り可能な送信者・受信者のフィールドを省略できる、ということです。完全な匿名性は、バイト列だけではなく運用全体の構成に左右されます。この区別が最も重要になるのは、内部告発者の証拠 のような、利害の大きい場面です。

証明は法的証拠として受け入れられることを保証するのか

いいえ。裁判所・規制当局・仲裁人・取引相手は、それぞれに適用されるルールのもとで、どの証拠を受け入れるかを自ら決めます。暗号学的な証明は、完全性とタイミングについて説得力のある証拠になり得ますが、万能の法的フリーパスではありません。

法域や契約によっては、適格タイムスタンプ、公証人、規制されたトラストサービス、あるいは特定の署名方式が求められる場合があります。別の場合には、公開ブロックチェーンの証明が、より広い証拠パッケージの一部として実質的な重みを持つこともあります。どちらが当てはまるかは、法域と案件によります。

証明が法的に重要になるときは、弁護士に相談してください。証明はタイミングと完全性の確立を支えることはできますが、法的助言の代わりにはなりませんし、この記事も法的助言ではありません。存在証明が紛争で果たしがちな実践的な役割は、法的証拠とeディスカバリー で整理しています。

証明をどう強くするか

実際に必要とする主張に合った層を、そしてその層だけを追加します。

  • タイミングが必要なとき。 ハッシュを公開するか、多数のファイルをまとめるなら Merkle ルートを公開します。
  • 著作者や承認が必要なとき。 Label 309 レコードに署名し、署名鍵を適切に管理します。
  • バイト列の回復が必要なとき。 ファイルを封印し、暗号化された暗号文を保管します。
  • 秘密の引き渡しが必要なとき。 受信者の受信アドレスに対して暗号化します。
  • 大量の証拠が必要なとき。 単一の Merkle ルートにコミットし、リーフリストと包含証明を保管します。一つのアンカーが数千のファイルを代表でき、これは 数千のファイルに一つのレコード で扱っています。
  • 法的な重みが必要なとき。 証明を、ポリシー、契約、法域が求める場合の適格サービス、そして文書化された証拠保全の連鎖と組み合わせます。

各層は異なる問いに答えます。それらを積み重ねることで、ただのタイムスタンプが、意図した主張をぴったり担う証明へと変わります。

要点

証明は、実際に証明できることだけを語るときに、最も強くなります。

Label 309 は、公開された Cardano の時刻によるバイトレベルの存在を証明します。その上に、著作者の署名、封印による保全、秘密の引き渡し、Merkle バッチ処理を加えられます。真実・所有権・法・アイデンティティ・運用上のセキュリティ・プロセスの代わりにはならず、そのふりもしません。

その正直さは、設計上の弱点ではありません。それこそが証明を信頼できるものにしています。何を裏付けるのか、そして何を残りの証拠に委ねるのかが、常に正確にわかるからです。

さらに読む

proof-of-existencetrustlabel-309