Label 309 レコードを検証する方法

Label 309 レコードは、公開された Cardano チェーンから直接検証できます。出発点となる入力は 1 つ、Cardano のトランザクション参照だけです。その答えは、CardanoWall にも、レコードを公開した人にも、どこかのサーバーが稼働し続けているかどうかにも依存しません。

検証ツールは、公開された Cardano インフラから生のトランザクションバイト列を取得し、メタデータラベル 309 を抽出し、レコード本体を再構成し、正規 CBOR とスキーマを確認し、署名があれば著者性の署名を検証します。そしてコンテンツのバイト列や暗号化されたペイロードが手に入る場合には、ハッシュを再計算します。この一連のチェックは、信頼されたサービスへのリクエストではなく、暗号学的な比較の連鎖です。

レコードを公開したゲートウェイは権威ではありません。権威はレコードそのものにあります。これがこの標準の要点です。一度検証した証明は、誰でも、いつまでも、Label 309 に準拠したあらゆるツールで検証し続けられます。

検証には何が必要か

最小限の入力は、Cardano のトランザクションハッシュです。

そのトランザクションハッシュだけでも、検証ツールは次の問いに答えられます。

• このトランザクションに Label 309 レコードはあるか
• レコードは構造的に正しいか
• トランザクションは十分な深さで確定しているか
• 署名がある場合、レコードレベルの署名は検証できるか
• レコードが主張しているハッシュ、ストレージ URI、Merkle ルート、封印エンベロープは何か

特定のファイルがそのハッシュの裏にあるファイルであることを証明するには、検証ツールはさらに、ファイルのバイト列か、レコードが参照する帰属可能なストレージオブジェクトを必要とします。

封印付きレコードを復号するには、検証ツールは受信者の秘密鍵を必要とします。その鍵はローカルで使われ、公開した人にも CardanoWall にも送り返されることは決してありません。この構造全体は、検証が決して外部に問い合わせないように設計されています。

検証ツールは実際に何を確認するのか

優れた検証ツールは、レコードを階層に分けて確認します。

第 1 層は構造バリデーター（structural validator）です。これはレコードのバイト列に対する純粋関数です。ネットワーク呼び出しも、復号も、署名の検証も行いません。確認するのは、正規 CBOR、フィールドの型、クローズドスキーマ、登録済みのアルゴリズム名、URI のルール、そして「少なくとも 1 つの item か 1 つの Merkle コミットメントがなければならない」といったフィールド間の制約です。

第 2 層はパブリック検証ツール（public verifier）です。検証ツールが選んだ Cardano データソースからトランザクションを解決し、取得したバイト列をトランザクションハッシュに結び付け、ラベル 309 を抽出し、確認深度を確認し、レコードの署名を検証します。これは、公開監査、CI ジョブ、エクスプローラーが実行できる層です。

第 3 層は受信者検証ツール（recipient verifier）です。パブリック検証ツールが行うすべてを実行したうえで、受信者のローカル鍵で封印された item の復号を試み、復号後に平文のハッシュを再計算します。

この階層化が重要なのは、すべての証明がすべてのチェックを必要とするわけではないからです。ハッシュのみのレコードは、暗号化されたペイロードがなくても有効であり得ます。パブリック検証ツールは、封印されたファイルを復号できなくても、署名付きレコードを検証できます。

なぜ JSON ビューではなく生のトランザクションバイト列から検証するのか

Label 309 の検証は、便利な JSON 射影ではなく、生のチェーンデータから動作します。この違いは見た目だけの問題ではありません。

レコードは正規 CBOR です。署名はバイト単位で厳密な正規 CBOR を対象とします。Cardano のトランザクションメタデータには、バイト列、テキスト文字列、配列、マップ、そして順序のルールがあり、JSON はこれらを欠落なく保持できません。

そのため検証ツールは、生のトランザクション CBOR を取得し、トランザクション ID を再計算し、補助データをトランザクション本体に結び付け、そのうえでラベル 309 のチャンク配列を元のレコード本体に再構成すべきです。

エクスプローラーは役に立つインフラであり得ます。しかし、信頼の対象にすべきではありません。検証ツールは、エクスプローラーの応答を、結び付け、確認し、相互照合するためのデータとして扱うべきです。

ラベル 309 レコードの中身は何か

Label 309 レコードは、Cardano のトランザクションメタデータラベル 309 の下に運ばれます。

オンチェーンの値は、ばらばらの JSON オブジェクトではありません。レコード本体は正規 CBOR として一度シリアライズされ、その後バイト列チャンクの配列として転送されます。Cardano のメタデータでは、バイト列もテキスト文字列も 64 バイトに制限されているためです。

再構成後、レコード本体は単一の CBOR マップになります。そのトップレベルのキーは次のとおりです。

• v、スキーマバージョン（現在は 1）
• items、コンテンツごとのコミットメントの省略可能な配列。各 item は必須の hashes マップを持ち、任意でコンテンツアドレス指定ストレージ（ar://、ipfs://）のための uris リストと、封印されたコンテンツのための enc エンベロープを持ちます
• merkle、1 つのオンチェーンルートをオフチェーンのリーフリストに結び付ける省略可能なリストコミットメント。大規模なバッチを記録する方法です
• sigs、省略可能なレコードレベルの著者性の署名
• supersedes、以前のレコードを指す省略可能な追記専用のポインタ
• crit と名前空間付きの拡張キー。前方互換な追加のためのものです

準拠したレコードは、少なくとも 1 つの items エントリか 1 つの merkle コミットメントにコミットしなければなりません。ストレージ URI と封印エンベロープは、トップレベルではなく item の内側に存在します。これは、レコードを自分でパースするときに正しく理解しておく価値のある点です。

中心となる主張は常にコンテンツ・ファーストです。これらのハッシュ、またはこの Merkle ルートが、ブロック時刻までにこのトランザクションで記録された、という主張です。

自動化はどのような判定を想定すべきか

検証は、あらゆる問題を「有効」か「無効」かに押し込めるべきではありません。

Label 309 の検証ツールモデルは、機械可読な 4 つの判定を用います。

• valid、必須のチェックがすべて通った
• failed、レコード自体が構造、署名、または帰属可能な完全性のチェックに失敗した
• unverifiable、レコードに帰属しない理由（利用できないインフラや取得できなかったコンテンツなど）で、必須のチェックを完了できなかった
• pending、トランザクションはチェーン上にあるが、検証ツールの確認しきい値を下回っている

この区分は、実際のシステムで重要になります。

ストレージゲートウェイが停止していても、レコードを断罪すべきではありません。取得したバイト列がコミットされた URI に帰属可能で、そのハッシュが一致しない場合、レコードは失敗とすべきです。トランザクションの確認が 1 つだけなら、検証ツールは、すでにファイナリティに達したかのように扱うのではなく、pending と表明すべきです。

オープンソースの cardanowall CLI は、これらの状態をそのまま終了コードに対応付けます。そのため、JSON をパースしなくても、判定がそのままシェルスクリプトに引き継がれます。

cardanowall verify <tx-hash> --json

この区分こそ、継続的インテグレーションで求められるものです。スクリプトは、「証明が不正である」（終了コード 1。挙動の不正なエクスプローラーが作り出すことは決してできません）と「後でやり直す」（終了コード 2）を区別できます。同じ検証ツールが TypeScript、Python、Rust の各 SDK に同梱されているため、アプリケーションは終了コードの代わりに完全な構造化レポートを読み取れます。これをパイプラインに組み込むためのパターンについては、CLI を自動化で使うを参照してください。

ファイルはどのように検証するのか

単純なファイル証明の場合、手順は次のとおりです。

1. トランザクションハッシュを用意します。
2. Label 309 レコードを取得して検証します。
3. コミットされたハッシュアルゴリズムとダイジェストを特定します。
4. ファイルのバイト列をローカルでハッシュ化します。
5. 計算したダイジェストを、レコード内のダイジェストと比較します。
6. 確認深度とブロック時刻を確認します。
7. レコードの署名があれば、それを確認します。

ファイルが 1 バイトでも違えば、ハッシュは違ってきます。

これがコンテンツハッシュ証明の強みです。これは、ファイルが真実であること、合法であること、オリジナルであること、価値があることを証明するものではありません。証明するのは、ハッシュに一致する正確なバイト列が、検証ツールのファイナリティポリシーに従い、記録されたブロック時刻までに存在していたという事実です。

封印付きレコードはどのように検証するのか

封印付きレコードは、暗号化されたコンテンツを加えます。

公開されたレコードは、それでも平文のハッシュにコミットします。暗号文は、たとえば Arweave や IPFS を通じてオフチェーンに保存できます。オンチェーンのエンベロープには、意図された受信者がコンテンツ鍵をローカルで復元するために必要な情報が含まれます。

受信者検証ツールは次を行うべきです。

1. まずパブリック検証の経路を実行します。
2. 与えられた秘密鍵を、封印されたスロットに対して試します。
3. スロットが開いたら、暗号文を復号します。
4. 平文のハッシュを再計算します。
5. それをオンチェーンのハッシュコミットメントと比較します。

この最後のハッシュチェックこそ、「何かを復号した」と「これがタイムスタンプを付与された正確なコンテンツである」とを結ぶ橋渡しです。バイト列を復号するだけでは不十分です。再計算した平文のハッシュは、何かが暗号化される前にレコードが行ったコミットメントと一致しなければなりません。

受信者の鍵はローカルにとどまります。検証には、信頼された CardanoWall アカウントも、発行者のサーバーも、レコードを公開した人へのコールバックも必要ありません。封印付きレコードは、平文を鍵保有者だけの機密に保ちます。ただし、その限界には注意してください。封印付きレコードは匿名性を保証しませんし、受信者がいったんコンテンツを復号すれば、その平文を好きなように扱えます。

Merkle コミットメントはどのように検証するのか

Merkle コミットメントは、バッチのためのものです。

数千ものハッシュを 1 つのレコードに直接公開する代わりに、生成者は 1 つの Merkle ルートを公開し、順序付きのリーフリストと包含証明をオフチェーンに保持できます。

バッチの中の 1 つの item を検証するには、次のようにします。

1. その item をハッシュ化するか、コミットされたリーフのダイジェストを入手します。
2. 包含証明を Merkle ルートに対して検証します。
3. ルートと leaf_count が Label 309 レコードに含まれていることを確認します。
4. Cardano のトランザクションと確認深度を検証します。

ルートだけでは不十分です。生成者またはアーカイブは、リーフリストと包含証明を保全しなければなりません。Label 309 はバッチに公開のアンカーを与えますが、バッチを取り巻く運用上の証拠は、依然として保持し続ける必要があります。これが、1 つのレコードで数千のファイルを証明する仕組みであり、オンチェーンのコストは一定です。

何を信頼すべきでないか

公開者のウェブサイトを真実の出どころとして信頼してはいけません。

トランザクションのスクリーンショットを信頼してはいけません。

JSON のエクスプローラービューを暗号学的な入力として信頼してはいけません。

ストレージゲートウェイを、単にバイト列を返したという理由だけで信頼してはいけません。

何を確認したのか示さない「検証済み」バッジを信頼してはいけません。

検証ツールは、次を含むレポートを生成できるべきです。トランザクションハッシュ、使用した Cardano データソース、確認深度、ブロック時刻、レコードのダイジェスト、署名の結果、コンテンツハッシュの結果、ストレージ取得の結果、Merkle のチェック、そしてスキップされたチェックです。

このレポートこそ、証明を監査と自動化で利用できるものにします。

検証は何を証明しないのか

検証は厳密です。誇張して売り込むべきではありません。

有効な Label 309 レコードは、それ自体では次を証明しません。

• コンテンツの法的な所有権、またはそれに対する独占的な権利
• コンテンツが真実であること
• 公開者がそれを公開する許可を得ていたこと
• 現実世界の人物が署名鍵を制御していること
• 裁判所、規制当局、または顧客が、裏付けとなる証拠なしにその証明を受け入れること。証拠能力は法域に依存し、証明は主張を支える場合がありますが、弁護士の代わりにはなりません
• オフチェーンのストレージが永遠に利用可能であり続けること。ストレージの永続性を別途維持しない限り、これは保証されません

証明するのは、レコードが実際に行う主張です。すなわち、ハッシュまたは Merkle ルートが Cardano 上に記録されたこと、レコードに対する署名があればそれが検証されたこと、そしてコンテンツや復号のチェックがあればそれがコミットメントと一致したことです。言い換えれば、これは時刻と完全性を立証するのであって、真実、所有権、権利を立証するのではありません。

その、より限定された主張こそが、まさに有用さの源です。タイムスタンプができること・できないことの全体像については、証明が証明しないことを参照してください。

さらに読む

• 完全な検証パイプライン、判定状態、型付きエラーカタログを含む Label 309 標準: label309.org。
• オープンソースの検証ツール。cardanowall CLI に加えて、いずれも同じチェックを実行する TypeScript、Python、Rust の各 SDK: github.com/cardanowall。
• Label 309 は Cardano の CIP プロセスに提出され、Metadata カテゴリの提案として CIP エディターによる審査中です: 公開中のプルリクエスト。