ハッシュ・署名・封印・共有：CardanoWall の証明を構成する 4 つのレベル

CardanoWall の証明には実用上 4 つのレベルがあり、どこまで階段を上るかはご自分で選べます。

ハッシュは、その特定のバイト列が公開された時刻までに存在したことを証明します。
署名は、特定のアイデンティティがそのレコードを保証したという、鍵に裏打ちされた主張を加えます。
封印は、元のファイルを暗号化し、証明とともに非公開で保全できるようにします。
共有は、その封印したファイルを特定の受信者向けにラップし、受信者が後から自分の鍵で見つけて復号できるようにします。

各レベルはその下のレベルの上に積み上がり、すべての土台にある同じ標準が Label 309 です。これが CardanoWall を理解する一番シンプルな見方になります。CardanoWall は、単にハッシュをブロックチェーンに置く場所ではありません。レコードを永続的で、非公開で、検証可能なものにするための、層状の仕組みなのです。素のタイムスタンプから始めて、その状況が実際に求める保護だけを加えていきます。

レベル 1：ハッシュ〜特定のバイト列がある時刻までに存在したことを証明する

最初のレベルは、古典的な存在証明（Proof of Existence）です。

ファイル、メッセージ、データセット、メディアアセット、ビルド成果物、レポート、マニフェストのいずれかを用意します。CardanoWall はその特定のバイト列の暗号学的ハッシュを計算し、そのハッシュを Cardano 上の Label 309 レコードとして公開します。

後から、同じ元のバイト列を持つ人は誰でも、もう一度ハッシュを計算できます。それがレコード内のハッシュと一致すれば、検証者は、その特定のバイト列がトランザクションのブロック時刻までに存在していたことを確認できます。このチェックは公開された Cardano チェーンに対して実行されます。CardanoWall のアカウントは不要で、CardanoWall のサーバーを信頼する必要もありません。

便利なのは、ファイルそのものを公開する必要が一切ないという点です。非公開の契約書、データセットのスナップショット、ソフトウェアのリリースマニフェスト、法的証拠の一式は、いずれも公開の証明を伴わせることができます。レコードが語るのはこれらのバイト列は存在したということです。バイト列そのものを見せる必要はありません。

ハッシュ証明は何の役に立つのか

ハッシュ証明は、問いが時系列と完全性に関するものであるときに強みを発揮します。次のような問いに答えられます。

この特定のファイルは、締め切りより前に存在したか。
これは先月タイムスタンプを付与したものと同じ PDF か。
このリリースマニフェストは、インシデントより前にすでにコミットされていたか。
このデータセットのスナップショットは、モデルがそれで学習される前に存在したか。
このメディアファイルは、編集や係争が起きる前に存在したか。

効率的でもあります。数ギガバイトのファイルが 1 つの短いダイジェストに圧縮され、非公開のファイルは中身を開示することなく公開のコミットメントになります。

その限界も同じくらい重要です。ハッシュは、誰がそのファイルを作成したか、そのファイルが真実であるか、誰かがそれを所有しているかを証明するものではありません。証明するのは、その特定のバイト列が公開された時刻までに存在したことだけです。それ以上ではありません。多くのワークフローではこれで十分です。それ以外については、CardanoWall が次の層を加えます。

レベル 2：署名〜レコードにアイデンティティの鍵を結び付ける

2 つ目のレベルは署名を加えます。

署名により、鍵がレコードを保証できるようになります。バイト列が存在したことを証明するだけでなく、特定のアイデンティティの鍵がその証明に署名したことも示せます。Label 309 において、これはレコード本体に対する任意の分離された COSE_Sign1 署名であり、誰が作者かを示すことは決して必須ではありません。署名のないレコードも、完全で、十分に検証可能な証明です。

この選択肢は、実用上の意味を変えます。個人のクリエイターにとっては、署名付きレコードは制作物をそのクリエイターの CardanoWall アイデンティティに結び付けられます。企業にとっては、承認された鍵がレポート、リリースマニフェスト、コンプライアンスのスナップショット、データセットのコミットメントの裏付けとなったことを示せます。自動化されたワークフローにとっては、「誰かがこのファイルにタイムスタンプを付与した」と「当社のシステムがプロセスの一環としてこのレコードに署名した」を区別できます。

署名はハッシュを置き換えるものではなく、その上に乗るものです。

ハッシュが語るのはこの特定のバイト列は存在したということです。
署名が語るのはこの鍵が、その主張を行うレコードに署名したということです。

署名が証明しないものとは何か

署名は強力ですが、魔法ではありません。

署名は、署名時点でその鍵を管理していたことを証明します。署名それ自体が、その鍵の背後にいる人物や企業の現実世界のアイデンティティを証明するわけではありません。そのアイデンティティは文脈から生まれます。鍵がどう作られたか、どう公開されたか、組織がどう管理しているか、そして他者がどのようにそれを信頼するに至ったか、です。

署名はまた、署名者がトランザクション手数料を支払ったことや、トランザクションを Cardano に提出したことを証明するものでもありません。Label 309 では、署名はレコード本体を対象とし、Cardano トランザクション全体を対象とはしません。これは意図的なもので、レコードのポータビリティを保つための設計です。ゲートウェイ、自動化システム、あるいは任意の第三者は、コンテンツの著者になることなく署名付きレコードを公開できます。検証された署名は「この鍵によって署名された」と読み取れるのであって、「この鍵がトランザクションを提出した」とは決してなりません。

平たく言えば、署名するのは、証明に「これは存在した」だけでなく「このアイデンティティが証明の裏付けとなった」と語らせたいときです。

レベル 3：封印〜暗号化したコピーを証明とともに保全する

3 つ目のレベルは、暗号化による保全を加えます。

ハッシュのみの証明には、実用上の弱点が 1 つあります。検証者は依然として元のバイト列を必要とするのです。ファイルを失ったり、たった 1 バイトでも変えてしまったりすると、レコードに一致するコンテンツをもはや作り出せなくなります。

封印はこれを、ファイルを暗号化し、暗号化されたペイロードを証明とともに ar:// や ipfs:// のようなコンテンツアドレス指定の保存先に保持することで解決します。オンチェーンのレコードは依然として平文のハッシュにコミットし、暗号文には決してコミットしません。そのため、タイムスタンプの主張は変わりません。ファイルが平文のまま公開されることはありません。正しい鍵を持つ人は後から、暗号文を取得し、復号し、平文のハッシュを再計算して、これがレコードの背後にあるファイルだと証明できます。

これは体験を変えます。ハッシュのみの証明では、元のファイルはご自分で保管します。封印付き証明では、元のファイルの暗号化されたコピーを、証明のワークフローそのものの一部として保全できます。

封印に価値があるのはどんなときか

封印が意味を持つのは、元のファイルが、失えば証明を弱めてしまうほど重要な場合です。次のようなものを考えてみてください。

法的証拠の一式や署名済みの契約書
コンプライアンスレポートや機微なインシデントログ
オリジナルのクリエイティブファイルや研究データ
データセットのマニフェスト、AI のプロンプトと出力、リリース成果物

いずれの場合も、ハッシュは有用ですが、後から提出する必要が出てくるのは元のバイト列です。封印付き存在証明なら、タイムスタンプは公開のまま保ちつつ、それらのバイト列を暗号化して保管できます。チェーンが時系列を証明し、暗号化がコンテンツを保護します。

レベル 4：共有〜封印したファイルを特定の受信者へ届ける

4 つ目のレベルは、非公開の受信者配信を加えます。

証明はご自分のためだけのものとは限りません。暗号化された証拠を、弁護士、監査人、パートナー、ジャーナリスト、顧客、規制当局、あるいは社内チームへ送る必要があるかもしれません。

受信者の受信アドレスが分かっていれば、CardanoWall は、受信者が後から自分の鍵で開封できる封印付きレコードを作成できます。そのレコードも依然として公開のタイムスタンプを持ち、依然として平文のハッシュにコミットします。暗号化されたファイルを保全することもできます。ただし今度は、暗号化されたペイロードを開封できるのが送信者だけでなく、特定の受信者になります。ここで CardanoWall は、タイムスタンプ付与ツールというより、安全なレコード配信システムのように感じられ始めます。

公開アドレス帳なしに、非公開の配信はどう機能するのか

受信者への配信に、チェーン上の公開アドレス帳は不要です。また、受信者の公開鍵が読み取り可能なフィールドとしてレコードに書き込まれることも一切ありません。

流れは次のとおりです。受信者は受信アドレスを持っています。送信者はそれを帯域外で入手します。受信者から直接、あるいはプロフィール、会社のページ、その他の信頼できるチャネルから取得します。送信者が封印付きレコードを構築すると、エンベロープは、意図された受信者だけが開封できる受信者ごとの暗号化された鍵スロットを保持します。

受信側では、受信者のソフトウェアが公開されている封印付きレコードをスキャンし、試行復号（trial-decrypt）を行います。各スロットを自分の鍵でローカルに 1 つずつ試すのです。あるスロットが開けば、そのレコードはその受信者の受信トレイに現れます。サーバーがメッセージを復号することは決してなく、受信者が誰であるかを知る必要もありません。（受信者側の詳細は封印付きレコードを受け取る方法をご覧ください。）

これは完全な匿名性の約束ではありません。タイミング、支払いの流れ、ネットワークのメタデータ、ブラウザの挙動、運用上のミスは、依然として情報を漏らし得ます。また受信者は、いったん復号した平文をいつでも共有できます。この設計が提供するのは、もっと限定的で、現実的なものです。Label 309 レコードそれ自体は、平文も、人間が読める受信者リストも公開しません。観察者に見えるのは、レコードが封印されていることと、いくつの鍵スロットを保持しているかだけで、誰宛てかは決して見えません。

なぜポスト量子暗号が共有の話に関わってくるのか

封印付きレコードは、非常に長く存続し得ます。暗号化されたコンテンツが恒久的、あるいは半恒久的に保存される場合、攻撃者は今日それを破る必要はありません。今のうちに暗号文を保存しておき、より優れたハードウェアとより優れた暗号解読を使って後から試せばよいのです。これが「今収集し、後から復号する（harvest now, decrypt later）」問題です。

だからこそ Label 309 はアルゴリズムの俊敏性を重視します。受信アドレスには 2 つの形式があります。古典的な X25519 アドレスと、X25519 を ML-KEM-768 と組み合わせた任意のハイブリッドなポスト量子アドレス（X-Wing 方式の構成）です。ハイブリッドは、古典的な X25519 の安全性を下限として保ちながら、将来の量子攻撃者への耐性を加えます。そのため、今日の暗号学的前提より長く存続させたいコンテンツには、こちらがより適したデフォルトになります。狙いは恒久的な安全性を主張することではありません。誠実であろうとすれば、それは主張できないのです。狙いは、今日の暗号学的な安心が永遠に続くと前提するような証明システムを設計してしまわないことです。

ユーザー向けの説明はシンプルなままです。Identity Seed（アイデンティティの種）を守ること、受信者がハイブリッドなポスト量子の受信アドレスを公開しているときはそちらを選ぶこと、そして暗号処理はソフトウェアに任せることです。

4 つのレベルはどう組み合わさるのか

これらのレベルは別々の製品ではありません。1 つの標準の上の層です。

タイムスタンプだけが必要なときは、素のハッシュ証明を公開します。
アイデンティティの鍵にレコードを保証させたいときは、署名を加えます。
元の特定のバイト列を保全することが重要なときは、ファイルを封印します。
特定の受信者が非公開のアクセスを必要とするときは、封印したファイルを共有します。

同じ基盤となる標準があらゆる選択を支えているため、シンプルに始めて、状況が求めるときにだけより強い層に手を伸ばせます。

どのレベルを使うべきか

ハッシュは、元のファイルを保管しやすく、唯一の問いがそのバイト列がある時刻までに存在したかどうかであるとき。
署名は、鍵に裏打ちされたアイデンティティに証明の裏付けとなってほしいとき。
封印は、元のバイト列が機微あるいは重要で、暗号化したコピーを証明とともに保全する価値があるとき。
共有は、他の誰かが暗号化されたコンテンツを受け取り、後から検証する必要があるとき。

4 つすべてを横断する 5 つ目のツールもあります。Merkle バッチ処理です。1 つずつ公開するにはハッシュが多すぎるとき、つまり CI/CD の成果物、日次ログ、データセットのスナップショット、生成メディア、その他、何千もの項目を単一のレコードとルートの下にコミットすべきあらゆるワークフローのためのものです。

これらの証明が、それでも証明しないものとは何か

4 つのレベルすべてをもってしても、存在証明はその主張について厳密であり続けます。

存在証明は、特定のバイト列が存在したこと、ある鍵がレコードに署名したこと、暗号化されたコンテンツが保全されたこと、コンテンツが特定の鍵へ配信されたこと、そして Merkle ルートがあれば、ある項目がコミットされたバッチに属していたことを証明できます。

それ自体では、コンテンツが真実であること、誰かが法的な所有権を持っていること、データセットが適法に収集されたこと、脆弱なプロセスが健全であることを証明するものではありません。こうした境界についての詳しい話は、証明が証明しないものをご覧ください。CardanoWall は永続的な証明の層を提供しますが、その証明を取り巻く業務プロセスは依然として重要です。

ひとことで言えば

ハッシュはタイムスタンプです。
署名はアイデンティティの主張です。
封印は暗号化による保全です。
共有は非公開の配信です。

これらが揃うことで、存在証明はチェーン上の素のハッシュから、ファイル、データセット、証拠、ソフトウェアのリリース、AI の出力、機密レコードのための実用的なワークフローへと変わります。そして Label 309 はオープンソースのツールを備えたオープンな標準であるため、同じ 4 つのレベルが、ウェブサイト、CLI、あるいは他の誰かの実装を通じて同じように機能します。

さらに読む

存在証明とは何か〜ハッシュのレベルを掘り下げます。
封印付きレコードを受け取る方法〜「共有」の受信者側について。
何千ものファイルを 1 つのレコードで〜 4 つのレベルすべてにわたる Merkle バッチ処理。
証明が証明しないもの〜心に留めておくべき限界。
Label 309 〜オープンな標準。Cardano の CIP プロセスに提案され、CIP エディターによる審査中です（PR #1205）。
github.com/cardanowall 〜オープンソースの SDK と cardanowall CLI。