Label 309 の仕組み

Label 309 は、存在証明（Proof of Existence）のレコードを Cardano のトランザクションメタデータにどう書き込むかを定義します。中核では、レコードが 1 つ以上のコンテンツハッシュをメタデータラベル 309 のもとで Cardano にコミットします。そのトランザクションのブロック時刻が、まさにそのバイト列がその瞬間までに存在していたことを示す公開された証人となります。レコードがそのほかに保持できるものは、すべてその 1 つの主張に関する任意のメタデータです。署名、ストレージ URI、暗号化されたペイロード、受信者ごとの鍵スロット、Merkle ルート、以前のレコードへのポインターなど、いずれも任意です。

設計目標は単純に言い表せます。証明は独立して検証可能であるべきだ、ということです。基本的な主張を確かめるのに、CardanoWall や発行者のウェブサイト、非公開のデータベース、認証局を信頼する必要はありません。必要なのは公開チェーンだけであり、コンテンツに関する主張については元のバイト列だけです。

Label 309 はオープンスタンダードです。メタデータカテゴリーの提案として Cardano の CIP プロセスに提出され、現在 CIP エディターによる審査中です。メタデータラベルそのものが、耐久性のあるオンチェーンの識別子です。ウェブアプリ、CLI、SDK は、標準そのものではなく、その参照実装です。まず全体像をつかみたい場合は、存在証明とは何かから読み始めてください。

ラベル 309 のもとでブロックチェーンに何が保存されるのか

Label 309 レコードは、整数ラベル 309 のもとで Cardano のトランザクションメタデータに格納されます。トランザクションごとにレコードは 1 つだけです。検証ツールはそれ以外のメタデータラベルをすべて無視します。

レコード本体は正規 CBOR としてエンコードされます。これは決定論的なバイナリ形式で、同じ論理レコードを表現する 2 つの実装は、バイト単位で同一のバイト列を出力します。 Cardano は単一のメタデータ文字列を 64 バイトに制限していますが、シリアライズされたレコードはたいていそれより大きくなります。そのため本体は、小さなバイト列チャンクの 1 つの CBOR 配列として転送されます。それらを順番に連結したものが、まさにレコード本体になります。検証ツールは、何かを検証する前にチャンクを連結し直します。この形式が行うチャンク化はこれだけです。

この転送の詳細は実装者にとって重要ですが、その下にある考え方は明快です。

トランザクションはメタデータラベル 309 を保持します。
そのラベルのもとの値は、1 つの Label 309 レコードに再構成されます。
レコードはコンテンツハッシュ、Merkle ルート、またはその両方にコミットします。
任意のフィールドが、署名、暗号化ペイロードの材料、ストレージ URI、置換ポインターを追加します。

これは自由記述のメモ欄ではありません。レコードは厳格で閉じた形を持ち、それこそが、異なる実装が同じバイト列を生成し検証できる理由です。

コンテンツハッシュが主たる主張であるのはなぜか

存在証明とは、まさにそのバイト列に関する主張であり、ハッシュとは、まさにそのバイト列の指紋だからです。

コンテンツハッシュは Label 309 における主たる主張であり、それ以外のフィールドはすべてそれに関するメタデータです。単純なファイルの証明では、1 つのアイテムが hashes マップを保持します。これは名前付きのハッシュアルゴリズム（たとえば sha2-256 や blake2b-256）と、32 バイトの生のダイジェストを対応づけます。証明を確認するには、検証ツールが元のファイルからダイジェストを再計算し、レコード内のダイジェストと比較します。

バイト列が一致すれば、証明は通ります。1 バイトでも変えればダイジェストが変わるので、証明は失敗します。

これが、コンテンツが大きくても非公開でも、主張を小さく保てる理由です。レコードはファイルそのものを必要としません。必要なのは指紋です。

items、uris、enc とは何か

items は、レコード内のコンテンツごとのコミットメントです。各アイテムは 1 つのコンテンツに関する主張です。必須なのは空でない hashes マップだけで、残りは任意です。

アイテムは次のものを保持できます。

hashes：ハッシュアルゴリズムと生のダイジェストを対応づける必須のマップ
uris：ar://…（Arweave）や ipfs://…（IPFS）のような、任意のコンテンツアドレス指定の保存先
enc：封印された（暗号化された）レコードのための任意の暗号化エンベロープ

肝心なのは、uris は証明ではないという点です。証明はハッシュです。URI は、検証ツールが確認すべきバイト列を見つける助けとなる取得のヒント、あるいはストレージへのコミットメントにすぎません。URI を持たないハッシュのみのレコードでも、完結した有効な証明です。URI を持つレコードは、公開コンテンツや暗号文の取得を助けられます。封印されたレコードは、平文をオフチェーンで暗号化したまま保ちつつ、それがいつ存在したかを証明します。

なぜ `ar://` と `ipfs://` だけなのか

Label 309 v1 は、ストレージ URI をコンテンツアドレス指定のスキーム、すなわち Arweave と IPFS に限定し、https:// を含むそれ以外をすべて拒否します。この制限は意図的なもので、一時的なものではありません。

通常の https:// の URL は、DNS、TLS、サーバーの挙動、リダイレクト、そしてのちにそのアドレスにたまたまホストされるものに依存します。コンテンツアドレス指定の URI は異なります。アドレスそのものがコンテンツから導出されるのです（IPFS の CID はバイト列のマルチハッシュであり、Arweave のトランザクション ID は Arweave のコンセンサスのもとでデータにコミットします）。そのため検証ツールは、ストレージゲートウェイや DNS、認証局を信頼することなく、「取得したバイト列は、作成者がコミットしたバイト列だ」と確認できます。取得したバイト列は、なおもオンチェーンのコミットメントと一致しなければなりません。ストレージレイヤーは、それ単独で真実の源になることは決してありません。

署名は何を証明し、何を証明しないのか

Label 309 レコードは、任意のトップレベル sigs 配列を保持できます。各エントリーは、 sigs フィールドを除いたレコード本体に対する分離された COSE_Sign1 署名です。平たく言えば、署名者はレコード全体を一度に保証します。あらゆるアイテム、あらゆるハッシュ、あらゆる URI、あらゆる封印エンベロープ、あらゆる Merkle ルート、置換ポインター、そして任意の拡張フィールドまでです。

署名は付加的です。署名のないレコードでも、なお存在を証明します。有効な署名を持つレコードは、特定の鍵がそのレコードの裏付けとなったことも 合わせて 示します。

ハッシュのみ：これらのバイト列はこの公開時刻までに存在した
署名あり：これらのバイト列はこの公開時刻までに存在し、かつこの鍵がレコードの裏付けとなった

この精度が重要なのは、署名が証明する範囲は、多くの人が思っているよりずっと狭いからです。検証済みの署名は、同じ鍵が Cardano のトランザクションの支払いや送信を行ったことも、ブロック時刻を選んだことも、特定の実在の人物に属することも、証明しません。証明するのは、その鍵がレコード本体に署名したことだけであり、それ以上ではありません。「この鍵によって署名された」と表現してください。「この鍵によって公開された」とは決して表現しないでください。その狭く正直な意味こそが、署名付き証明を異なるアプリやゲートウェイ間で持ち運び可能にするものです。著者であることは常に任意であり、検証ツールが確認できない署名（サポート外のアルゴリズム、解決できない鍵）が、存在の主張を無効にすることは決してありません。署名は穏やかに失敗しますが、存在は失敗しません。

封印付きレコードとは何か

封印付きレコードは、コンテンツを機密に保ちつつ、それがいつ存在したかを証明します。

封印付きの Label 309 レコードでは、アイテムはなお平文のハッシュにコミットします。暗号文には決してコミットしません。平文は暗号化され、暗号文はコンテンツアドレス指定の URI（ar://… や ipfs://…）に置かれ、チェーン上には決して置かれません。オンチェーンのレコードは暗号化エンベロープを保持し、その中には、選ばれた鍵の保有者がコンテンツ暗号化鍵を復元するために必要な材料が入っています。チェーンは平文を含まず、受信者のリストも公開しません。

受信者にとって、検証はいくつかの手順が加わります。

Cardano からレコードを取得します。
コンテンツアドレス指定ストレージから暗号文を取得します。
一致する鍵スロットをローカルで開こうと試みます。
スロットが開いたら暗号文を復号します。
平文のハッシュを再計算し、オンチェーンのコミットメントと比較します。

オンチェーンのダイジェストが平文を束縛しているため、封印付き証明は元のファイルをそのまま保持し、かつ非公開に保ちます。ただし、正直に言えばいくつかの限界も伴います。封印付きレコードが証明するのはタイミングと完全性であって、匿名性ではありません。そして復号した受信者は、そのあとで平文を漏らすことをいつでも選べます。

受信者フィールドなしで、受信者はどう機能するのか

受信者は、読み取り可能な宛先フィールドではなく、受信鍵と試行復号を通じて機能します。

送信者が受信者の受信アドレス（X25519 の公開鍵、任意でハイブリッドな耐量子のもの）を知っていれば、その受信者が開ける鍵スロットを持つ封印付きレコードを構築できます。受信者の公開鍵が、レコード内に読み取り可能なフィールドとして現れることはありません。受信者のソフトウェアは Label 309 レコードの公開ストリームを監視し、候補となるスロットの復号をローカルで試みます。スロットが開けば、そのレコードはその受信者の受信トレイに属します。

これが、CardanoWall の受信トレイが通常のサーバー側のメールボックスではない理由です。ゲートウェイは受信者を区別しないレコードのフィードを公開し、クライアントは自分が復号できるものを見つけます。サーバーは、受信者が誰であるかを知る必要も、受信者に代わって何かを復号する必要もありません。（実際の受信者側については封印付きレコードの受け取り方をご覧ください。）

それでも、はっきりさせておく価値のあるメタデータ上の限界はあります。レコードは平文も受信者の列も決して公開せず、スロットの順序は公開前にシャッフルされるため、なんの信号も帯びません。しかしスロットの数は見えますし、タイミングや支払いの痕跡、運用上のミスは、レコード形式そのものでは隠せない情報を明らかにし得ます。

1 つのレコードで、どうやって数千のファイルをカバーするのか

数千のファイルが存在したことを証明する必要があるとして、数千の Cardano トランザクションを要すべきではありません。Label 309 は Merkle バッチ処理をサポートします。ファイルをハッシュ化し、ハッシュの順序付きリストにわたる Merkle ツリーを構築し、レコードの merkle 配列に単一の 32 バイトのルートを公開します。ルートと並んで、レコードはリーフ数を保持し、これがオンチェーンのルートをオフチェーンのリストの正確なサイズに束縛します。

のちに、特定の 1 つのファイルやイベントがバッチに含まれていたことを、次のものを示すことで証明できます。

そのファイル（またはそのリーフハッシュ）
包含証明：ルートに至るパス上の兄弟ハッシュ
Label 309 レコードに記録された Merkle ルート

検証ツールは包含証明を折りたたんでルートへと戻し、再計算したルートが公開されたルートとバイト単位で等しい場合に限って受け入れます。開示されていないリーフはすべて非公開のまま残ります。ルートは、それがコミットするリーフについて何も明らかにしません。

これは、CI/CD のアーティファクト、コンプライアンスログ、AI の出力、データセットのマニフェスト、リリースフォルダー、証拠バンドルのためのスケーリングレイヤーです。これは 1 つのレコードで数千のファイルをで個別に取り上げます。

supersedes ポインターは何をするのか

supersedes は、以前の Label 309 レコードへの、そのトランザクションハッシュによる任意の 32 バイトのポインターです。新しいレコードに「これはあの以前のレコードを置き換える、または更新する」と言わせることができます。

以前のレコードは削除されず、無効化もされません。Cardano は追記専用なので、両方のレコードは永遠に独立して検証可能なまま残ります。ポインターは単なるリンクであり、理由フィールドは持ちません。置換の人間的な意味、すなわち訂正、改訂されたマニフェスト、更新された証拠パッケージといったものは、メタデータではなく、新しいコンテンツやアプリケーションレイヤーに属します。このポインターの価値は、ベンダーのデータベース行も独自のレコード ID もなしに機能することです。

検証はどう機能するのか

検証はレイヤー化されています。Label 309 は 3 つの検証ツールの役割を定義し、それぞれが直前のものを厳格に拡張します。

構造バリデーター（structural validator）：レコードのバイト列に対する純粋な関数です。正規 CBOR、スキーマの形、フィールドの型、必須フィールド、アルゴリズム識別子、URI のルールを確認します。ネットワーク I/O は行わず、署名を検証せず、何も復号しません。
パブリック検証ツール（public verifier）：Cardano のトランザクション参照から始めます。検証ツール自身が選んだエクスプローラーから生のトランザクションを取得し、それらのバイト列を要求されたトランザクションハッシュに束縛し、ラベル 309 の存在を確認し、レコードを再構成し、構造検証を実行し、確認深度を確認し、サポートする署名を検証します。コンテンツのバイト列が利用できれば、公開コンテンツのハッシュを再計算できます。復号はしません。
受信者検証ツール（recipient verifier）：パブリック検証ツールが行うすべてに加えて、封印されたペイロードを開いて平文のハッシュを再計算するための、自身の秘密鍵を持ちます。

検証を正直に保つ繊細な点が 1 つあります。パブリック検証ツールは、エクスプローラーのメタデータの JSON ビューではなく、生のトランザクション CBOR を読みます。JSON の射影は不可逆です。マップキーの順序と、バイト列か文字列かの区別を捨ててしまうのです。そこから再エンコードすれば、準拠したレコード上のあらゆる署名が壊れてしまいます。そして Cardano での確定は確率的であるため、わずか 1 〜 2 ブロックの深さしかないレコードは、十分な確認が背後にそろうまで、valid ではなく pending として報告されます。

この構造が、信頼モデルを清潔に保ちます。基本的な検証ツールは CardanoWall アカウントを必要としません。公開された証明は発行者サーバーなしで確認できます。封印された証明は、鍵の保有者の手元でローカルに復号されます。 Label 309 レコードを検証するの解説は、パブリック検証ツールの道筋を端から端まで示します。

ゲートウェイはどこに位置づけられるのか

ゲートウェイはレコードを公開します。信頼の根ではありません。

Label 309 ゲートウェイは、自分で運用するのが本当に難しい部分を扱います。価格を見積もり、暗号文をストレージにアップロードし、Cardano のトランザクションを構築して送信し、確認を待ち、レコードをインデックスし、残高を管理し、 API を公開します。CardanoWall はこのゲートウェイモデルを使って、一般のユーザーや開発者にとって公開を実用的なものにしています。

しかし、証明はゲートウェイが存在すると言ったから信頼されるのではありません。レコードがチェーン上にあり、バイト列が検証を通り、署名が確認でき、ハッシュが再計算できるからこそ信頼されます。それが、ホスティングされたサービスと証明標準を分ける線です。サービスは公開を助け、標準は誰もが検証できるようにします。そしてゲートウェイは信頼の経路から完全に外れています。

最小限のメンタルモデル

Label 309 を、小さくレイヤー化されたレコードとして捉えてください。

items は、まさにそのコンテンツのバイト列が公開時刻までに存在したことを証明します。
sigs は、任意で、鍵にレコードの裏付けをさせます。
enc は、暗号化されたコンテンツを非公開のまま、なお復元可能に保ちます。
受信者ごとの鍵スロットは、特定の鍵の保有者に、封印されたコンテンツを開かせます。
merkle は、1 つのレコードに、きわめて大きなバッチの代わりを務めさせます。
検証は公開データとローカルの鍵で動き、ベンダーへの信頼では決して動きません。

このレイヤー化こそが、CardanoWall がウェブアプリにも、API にも、CLI にも、デスクトップアプリにも、セルフホストのゲートウェイにもなれる理由です。そのあいだ、証明の形式は同じままです。プロダクトは変わり得ますが、証明は検証可能なまま残ります。

全体を通じて正直に言っておく価値のあることが 1 つあります。Label 309 の証明は、特定のバイト列が公開時刻までに存在し、それ以降変わっていないことを示します。コンテンツを誰が著したか、誰が所有しているか、そこに書かれていることが真実かどうかは証明しません。その線がどこに引かれるかについては、証明が証明しないことをご覧ください。

さらに読む

存在証明とは何か
Label 309 レコードを検証する
1 つのレコードで数千のファイルを
証明が証明しないこと
Label 309 標準：label309.org
オープンソースの SDK と CLI：github.com/cardanowall
Cardano CIP への提出（審査中）： CIPs PR #1205