レコード

Label 309 のレコードは、Cardano トランザクションのメタデータ内に label 309 のもとで格納される、ひとつの CBOR マップです。このマップは、ひとつ以上のコンテンツのハッシュ値をチェーン上に記録します。トランザクションのブロック時刻が、それらのバイト列があるブロックの時刻以前に存在していたことの証人となります。レコードが運べるそのほかの要素、すなわちストレージ URI、暗号化エンベロープ、著作者性のための署名、置き換え先を示すポインタなどは、いずれもこの中心的な主張に付随する任意のメタデータです。

このページでは、ワイヤー上での形を定義します。レコードがどこに置かれるか、どのようにエンコードされるか、サイズの大きすぎる値がどのように転送されるか、そして構造バリデーターが照合する閉じたスキーマがどのようなものかを扱います。ここで参照する暗号構成（ハッシュアルゴリズム、封緘済みエンベロープ、署名）には、それぞれ専用のページがあります。このページが扱うのはワイヤーフォーマットです。

レコードの格納場所

存在証明（Proof of Existence, PoE）のレコードは、トランザクションのメタデータ label 309 の下に置かれなければなりません（MUST）。このラベルは CIP-10 メタデータラベルレジストリ に「Proof of Existence record」として予約されています。トランザクションのメタデータは整数ラベルから値へのマップであるため、ひとつのトランザクションに PoE レコードを複数含めてはなりません（MUST NOT）。トランザクションごとにレコードはちょうどひとつです。

トランザクションは、ほかのラベルのもとに追加のメタデータを持つことができます（MAY）。たとえば CIP-20 の 674 メッセージなどです。PoE を処理する検証者は、309 以外のすべてのラベルを無視しなければなりません（MUST）。

Conway 期のレジャーでは、トランザクションのメタデータは、トランザクションの auxiliary_data 内の metadata フィールドに格納されます。いずれのラベルのもとでも、受け入れられる値はレジャーの再帰的な metadatum 型、すなわち整数、バイト文字列、テキスト文字列、配列、マップに制約されており、バイト文字列とテキスト文字列はいずれもそれぞれ最大 64 バイトです。

metadatum =
    { * metadatum => metadatum }
  / [ * metadatum ]
  / int
  / bstr .size (0..64)
  / tstr .size (0..64)

64 バイトを超える単一の bstr または tstr を含むトランザクションは、いかなる検証者の目に触れる前に、送信時点で Cardano ノードによって拒否されます。この上限こそが、Label 309 が転送時のチャンク分割の規律（後述）を定める理由です。レコードが運ぶすべてのフィールドは、基本フィールドであれ拡張フィールドであれ、metadatum に還元できなければなりません。

転送: 本体全体のチャンク配列

シリアライズされたレコード本体は通常 64 バイトを超えるため、裸の値として label 309 の下に格納することはできません。そこでレコード本体は、不透明な本体全体のチャンク配列として運ばれます。これは、最大 64 バイトのバイト文字列（bstr .size (1..64)）からなる単一の CBOR 配列であり、その順序どおりの連結が、レコード本体そのものになります。この転送のための分割こそが、Label 309 が行う唯一のチャンク分割であり、フォーマットの中で本当にレジャーに強いられている唯一のステップです。

レジャーが目にするのはこの転送配列だけであり、再組み立て後の本体の内側にあるフィールドを目にすることは決してありません。そのため、それらのフィールドはフィールドごとのチャンクラッパーも、フィールドレベルの 64 バイト上限も持たない通常の CBOR 値です。ストレージ URI は単一のテキスト文字列、COSE_Sign1 は単一のバイト文字列、X-Wing の kem_ct は単一の 1120 バイトのバイト文字列です。64 バイトを超えるフィールドは、本体のほかのどの区間とも同じように、本体全体の配列のチャンク境界をまたいで運ばれるだけです。

プロデューサーは、レコード本体を一度だけ正規 CBOR にシリアライズし、そのバイト文字列を 1〜64 バイトのチャンクに分割し、得られた確定長のバイト文字列からなる確定長の配列を label 309 の値として格納しなければなりません（MUST）。配列の形は、64 バイト以下の本体であっても常に必須です。そのような本体も、長さ 1 の配列であって、裸のマップやバイト文字列ではありません。プロデューサーは最小の分割（最後を除くすべてのチャンクをちょうど 64 バイトにする）を用いるべきであり（SHOULD）、長さゼロのチャンクを出力すべきではありません（SHOULD NOT）。過剰なチャンク分割は、何の利点もなくトランザクションのバイトを浪費します。

検証者は、構造検証を行う前に、配列の要素を順序どおりにバイト連結してレコード本体を再組み立てしなければならず（MUST）、そのような配列でない label 309 の値はすべて拒否しなければなりません（MUST）。チャンクの境界には意味的な意味はありません。連結結果がバイト単位で同一である 2 つの転送配列は、同じレコードを表します。運搬エラーの分類が拒否コードを固定します。64 バイトを超えるチャンクは CHUNK_TOO_LARGE、バイト文字列でない配列要素、不確定長の配列または要素、配列でない label 309 の値（裸のマップ、裸のバイト文字列、整数）は MALFORMED_CBOR です。長さゼロのチャンクはバイトを何も寄与せず、それ自体で拒否されることはなく、許容されます。

レコードマップ

再組み立て後のレコード本体は CBOR マップです。整数値のフィールドは CBOR のメジャータイプ 0/1、テキストフィールドはメジャータイプ 3 で有効な UTF-8 でなければなりません（MUST）。バイトフィールドはメジャータイプ 2、配列はメジャータイプ 4、ネストされたマップはメジャータイプ 5 です。存在する任意フィールドは、空の値を持ってはなりません（MUST NOT）。

トップレベルの構造は次の通りです。

適合するレコードは、items（1 エントリ以上）または merkle（1 エントリ以上）の少なくとも一方にコミットしなければなりません（MUST）。どちらも持たないレコード、あるいはいずれか一方を空配列として持つレコードは、空のレコードとして拒否されます。このルールを除けば、items と merkle は直交しています。どちらか一方だけを持つレコードも、両方を一緒に持つレコードも有効です。

Label 309 はエントリ数に数値的な上限を設けていません。唯一の上限は、その時点で有効な Cardano の最大トランザクションサイズであり、プロデューサーはバイト単位の手数料を支払うため、レコードサイズは自然と抑えられます。バリデーターは、レジャーのサイズ制限内に収まっている限り、エントリが多いというだけの理由でレコードを拒否してはなりません（MUST NOT）。

バージョンフィールド

v は CBOR の符号なし整数であり、セマンティックバージョンの文字列ではありません。このドキュメントが定義するのは v = 1 のみです。バリデーターは、サポート対象の集合の外にある v を持つレコードを、型付きエラーで拒否しなければなりません（MUST）。パニックや異常終了を起こしたり、そのレコードを別のメタデータスキーマとして黙って扱ったりしてはなりません（MUST NOT）。v の整数値が上がるのは、ある変更によって v1 パーサーがレコードを誤って解釈してしまう場合のみです。追加的かつ名前空間化された拡張では上がりません。

アイテム

items の各エントリは、ひとつの必須フィールドとふたつの任意フィールドを持つ CBOR マップです。

• hashes — 必須。ハッシュアルゴリズム識別子から生の 32 バイトのダイジェストへの、空でないマップ。少なくとも 1 エントリが必要です。CBOR マップのキーは一意であるため、アルゴリズムの重複は構造的に起こりえません。コンテンツとハッシュ化 を参照。
• uris — 任意。発見用 URI の複数形リスト（ルールは後述）。
• enc — 任意。封緘済みアイテムの暗号化エンベロープ。封緘済み PoE を参照。

アイテムごとの署名スロットはありません。著作者性はレコードレベルでのみ、すべてのアイテムを一様にカバーする sigs[] エントリによって表現されます。

Merkle コミットメント

merkle の各エントリは、正規のハッシュツリー構造によってレコードを 32 バイトのリーフの順序付きリストに結びつけます。これにより、チェーン上のひとつの 32 バイトのルートが、任意に大きなオフチェーンのリーフリストの代わりを務められます。コミットメントはクローズドなマップです。

Merkle ルートはリーフリストの構造にコミットするのに対し、hashes エントリは平文のバイト列にコミットします。両者は異なる方法で検証されます（包含証明 と 平文の再計算）。これが、リストコミットメントがアイテム内ではなくトップレベルに置かれる理由です。リストコミットメントのレジストリは、コンテンツハッシュのレジストリとは互いに独立しています — アルゴリズムレジストリ を参照。

Supersedes

supersedes は、ひとつの先行する Label 309 レコードを指す、任意の 32 バイトの Cardano トランザクションハッシュです。これはサービスに依存しない追記専用のリンクであり、後続のレコードが、オフチェーンのデータベースやベンダー固有のレコード ID を介さずに先行レコードを指せます。

置き換え（supersedence）は、先行レコードを削除・失効・無効化するものではありません。チェーンは追記専用であり、検証者は先行レコードを引き続き、存在し単独で検証可能なものとして扱わなければなりません（MUST）。このポインタには理由や自由記述のフィールドはありません。人間にとっての意味（訂正、置き換え、撤回など）は、新しいコンテンツに込めるべきものであって、label 309 に込めるものではありません。ポインタを解決する検証者は、それを含むトランザクションと同じ Cardano ネットワーク上でそれを参照しなければなりません（MUST）。トランザクションハッシュは自身のネットワーク内でのみ一意であるため、このフィールドにはネットワークの識別子は含まれません。

署名

sigs は、レコードレベルの署名エントリからなる任意の配列です。各エントリは、sigs を取り除いたレコード本体（つまりレコードマップ全体）に対する分離（detached）された COSE_Sign1 構造を保持し、ウォレット署名の経路のためには任意で署名者の公開鍵も保持します。ひとつの署名が、すべてのアイテム、すべての URI、すべてのエンベロープ、（存在すれば）置き換えポインタ、そしてあらゆる拡張キーを証明します。署名は常に任意であり、認識できない署名アルゴリズムがコンテンツの主張を無効にすることはありません。署名対象のペイロード、ドメイン分離のためのプレフィックス、署名者の鍵の解決、そして厳格な検証ルールは 署名 で規定されています。

URI のルール

uris は、存在する場合は空でないリストであり、各エントリはちょうどひとつの URI を運ぶ単一の CBOR テキスト文字列です。URI ごとの長さ上限も、ラッピングの形もありません。本体全体の転送がすでにレジャーの 64 バイト文字列上限を満たしているため、長い ipfs://<CIDv1>/<path> URI も、ほかと変わらないひとつのテキスト文字列です。各 URI は絶対 URI でなければならず（MUST）、スキームと階層部分を含まなければならず（MUST）、フラグメント識別子を含んではなりません（MUST NOT）。PoE はコンテンツのバイト列に関する主張であって、ドキュメントの下位要素に関する主張ではないためです。

v1 のスキームセットはクローズドであり、コンテンツアドレス指定です。

プロデューサーはこれ以外のスキームを発行してはなりません（MUST NOT）。https://、http://、file://、data: などはすべて拒否されます。この制限は意図的なものであり、一時的なものではありません。コンテンツアドレス指定の URI は、ストレージレイヤーの整合性モデルを通じて、フェッチしたバイト列を URI 自体に結びつけます（IPFS CID はコンテンツのマルチハッシュであり、Arweave トランザクション ID は Arweave のコンセンサスの下でデータにコミットします）。そのため検証者は、DNS、TLS、ゲートウェイ、認証局を信頼することなく、「フェッチしたバイト列が、プロデューサーがコミットしたバイト列と同じである」ことを確認できます。セット外のスキームが含まれるレコードは構造的に無効であり、valid として検証を通ることは決してありません。

uris は全体を通じて任意です。uris を省略したハッシュのみのレコードも、完結した主張です。コンテンツの存在は、取得経路にコミットせずに主張できます。受け入れられる CID プロファイル（マルチベースプレフィックス、コーデック、マルチハッシュ）の詳細は検証ルールの一部です。検証 を参照。

正規 CBOR

すべての Label 309 レコードは、RFC 8949 §4.2.1（Core Deterministic Encoding）に従って正規 CBOR としてエンコードされなければなりません（MUST）。具体的には次の通りです。

1. すべての整数に対して優先（最短形式）のシリアライゼーション。
2. すべてのバイト文字列、テキスト文字列、配列、マップに対して確定長エンコーディング。
3. セマンティックタグなし（このドキュメントでは不要です — bignum タグ 2/3 を使用してはなりません（MUST NOT））。
4. マップキーは CBOR エンコーディングのバイト辞書順でソート。
5. バイトオーダーマークなしの UTF-8 テキスト文字列。
6. いかなるマップにも重複キーなし。
7. 浮動小数点や非自明なシンプル値なし — レコードは整数、バイト文字列、テキスト文字列、配列、マップ、および（スキーマが許容する場合）true/false/null のみを保持します。メジャータイプ 7 の浮動小数点（整数値の 1.0 を含む）、負のゼロ、および undefined は拒否しなければなりません（MUST）。強制変換は不可です。

決定性こそが、このフォーマットを相互運用可能にするものです。同じ論理的なレコードを表現するふたつのプロデューサーは、バイト単位で同一のバイト列を出力するため、ある実装がレコード本体に対して計算した署名は、別の実装でも検証できます。バリデーターは、正規でないエンコーディングを拒否しなければなりません（MUST）。エクスプローラーやウォレットはメタデータを JSON プロジェクションで表示する場合がありますが、準拠した検証者は、その損失を伴う JSON への再エンコーディングではなく、元のトランザクションの CBOR を検証しなければなりません（MUST）。

前方互換性

Label 309 v1 は、クローズドな基本キーのセット v、items、merkle、supersedes、sigs、crit を予約しています。レコードはさらに、名前が次のふたつの予約された名前空間のいずれかに一致する拡張キーを持つことができます（MAY）。

• ^x-.+ — ベンダー / 実験用の名前空間。
• ^[a-z]+-.+ — コンパニオン仕様の名前空間。プレフィックスが、登録する仕様の名前を表します。

バリデーターは、拡張キーをデコードして保持しなければならず（MUST）、拡張キーが存在するというだけの理由でレコードを拒否してはならず（MUST NOT）、その内容を検証済みであると主張することなく、情報として提供しなければなりません（MUST）。拡張キーは署名済み本体の一部であるため、レコードレベルの署名がそれらをカバーします。リレーは、署名が生成された後に拡張キーを挿入することはできません。いずれのパターンにも一致しない未知のトップレベルキー（supersedess のようなタイポや、Sigs のような大文字小文字の異なる変種など）は、未知のフィールドとして拒否されます。パターンに基づくこの許容は、基本セットに対するタイポの検出を維持しつつ、将来の追加のために安定したプールを開いたままにします。

検証者に非基本フィールドの理解を求めるプロデューサーは、そのフィールドの名前をトップレベルの crit 配列に列挙しなければなりません（MUST）。実装していない crit エントリに遭遇した v1 検証者は、そのレコードを有効として報告してはなりません（MUST NOT）。各 crit エントリは、拡張キーのパターンに一致しなければならず（MUST、基本キーは crit では禁止です）、レコード内に実際に存在するフィールドを指していなければならず（MUST）、一意でなければなりません（MUST）。こうして、クリティカルマークは常に、検証者が理解する義務を負う具体的なフィールドへとたどれるようになります。これらのルールは、RFC 9052 §3.1（COSE crit）および RFC 7515 §4.1.11（JWS crit）における must-understand / must-ignore の先例に従っています。

バイト予算

レコードサイズに対する唯一のハード上限は、その時点で有効な Cardano の maxTxSize プロトコルパラメーターであり、メインネットのプロトコルメジャーバージョン 10 では 16 384 バイトですが、これはレジャーパラメーターの更新によって変わり得ます。Label 309 はそれを下回るスキーマレベルの上限を設けていません。この制限を超えるレコードは送信時点で Cardano ノードによって拒否されるため、検証者がそれを目にすることはありません。バリデーターは、maxTxSize を下回る Label 309 固有の上限を勝手に設けてはなりません（MUST NOT）。

実際には、トランザクションのメタデータ以外の部分（入力、出力、ウィットネス、手数料および有効期間のフィールド）がおよそ 245 バイトを消費するため、label 309 のレコードにはおよそ 16 KB が残ります。プロデューサーは、手数料の変動を吸収するために制限より数百バイト下を目標にすべきであり（SHOULD）、送信前に候補となるレコードのサイズを計算して、収まらない場合は早めに失敗すべきです（SHOULD）。実際に収まる形は十分に余裕があります。100 を優に超える単一ハッシュのアイテム、数十のレコードレベル署名、あるいは多数の古典的な受信者スロットが、いずれもひとつのトランザクション内に余裕をもって収まります。さらに、ひとつの Merkle ルートは、オンチェーンでは 32 バイトという固定コストで、上限のないオフチェーンのリーフリストにコミットします。

CDDL スキーマ

以下の CDDL は、再組み立て後のレコード本体の構造スキーマです。すなわち、label 309 の下に格納された最大 64 バイトのチャンク配列を連結して得られる正規 CBOR バイト列を対象としています。再組み立て後の本体は素の決定論的 CBOR です。それ自体はレジャーの metadatum ではなく、そのフィールドは 64 バイト文字列上限の対象ではありません。この上限は、本体全体の転送ラッパーだけが満たします。ラッパーはここではモデル化していません。

このブロックは、整形式の形の許容スーパーセットを記述しています。フィールド間の不変条件（items-or-merkle ルール、暗号化エンベロープにおける slots ⊕ passphrase の排他性、アルゴリズム識別子のレジストリへの所属、KEM ごとのスロット形のルール）は、CDDL 自体ではなく、デコード後の構造に対する型付き検証パスによって適用されます。

; An extension value is any CBOR value the canonical (deterministic) encoding
; profile admits. Floats and semantic tags are excluded by that profile (they
; are rejected as MALFORMED_CBOR on decode), so the exclusion is not repeated
; here; the reassembled body carries no field-level 64-byte cap.
extension-value =
    { * extension-value => extension-value }
  / [ * extension-value ]
  / int
  / bstr
  / tstr
  / bool
  / null

; A conformant record MUST carry at least one of `items` (>= 1 entry) or
; `merkle` (>= 1 entry); a record with both absent (or both empty) is rejected
; as SCHEMA_EMPTY_RECORD by the typed pass, not at the CDDL layer.
poe-record = {
  poe-common,
  ? "items": [ 1* item-entry ],
  ? "crit":  [ 1* tstr ],
  * extension-key => extension-value
}

poe-common = (
  "v": 1,
  ? "merkle": [ 1* merkle-commit ],
  ? "supersedes": bytes32,
  ? "sigs": [ 1* sig-entry ],
)

extension-key = tstr .regexp "^x-.+"
              / tstr .regexp "^[a-z]+-.+"

item-entry = {
  "hashes": hash-map,
  ? "uris": [ 1* uri ],
  ? "enc": enc,
}

; A non-empty CBOR map keyed by a content-hash algorithm identifier with the
; 32-byte digest as value. Map-key uniqueness makes duplicate algorithms
; structurally impossible.
hash-map = { + content-hash-alg => bytes32 }

; A list commitment binds the record to an ordered leaf list. `leaf_count`
; binds the on-chain commitment to the off-chain list size.
merkle-commit = {
  "alg":        merkle-commit-alg,
  "root":       bytes32,
  "leaf_count": uint32,
  ? "uris":     [ 1* uri ],
}

; `enc` is a choice between the scheme-1 envelope shape and a bounded opaque
; envelope (the degrade-to-opaque rule for an unsupported scheme/kem/aead). The
; typed pass enforces the slots/passphrase exclusivity and the per-KEM
; slot-shape rules over a supported envelope.
enc = enc-scheme-1 / enc-opaque

; `scheme: 1` is not a version counter for the `enc` map alone: it names the
; ENTIRE sealed cryptographic suite — the canonicalEncode rules, the slot
; schema, the HKDF and HMAC hashes, the wrap AEAD, the segmented-STREAM content
; format, the transcript schemas, the in-ciphertext passphrase commitment, the
; pinned X-Wing revision, every domain-separation label, and the Argon2id and
; passphrase-normalization profiles. Changing any one of them requires a new
; `scheme` value; see Sealed PoE for the construction it pins.
enc-scheme-1 = {
  "scheme": 1,
  "aead":   aead-alg,
  "nonce":  bstr,
  ? "kem":        kem-alg,
  ? "slots":      [ 1* slot ],
  ? "slots_mac":  bytes32,
  ? "passphrase": passphrase-block,
}

; The opaque reading of an envelope under an unsupported identifier: `scheme`
; is the only structurally required key, and every other entry is any key/value
; pair the canonical profile admits, subject to the generic decode bounds.
enc-opaque = {
  "scheme": uint,
  * tstr => extension-value
}

slot = classical-slot / hybrid-slot

; enc.kem = "x25519": the per-slot X25519 ephemeral public key + wrapped CEK.
classical-slot = {
  "epk":  bytes32,
  "wrap": bytes48,
}

; enc.kem = "mlkem768x25519": the 1120-byte X-Wing ciphertext plus the wrapped
; CEK. There is NO `epk` — the X25519 ephemeral is the trailing 32 bytes of the
; X-Wing ciphertext inside `kem_ct`.
hybrid-slot = {
  "kem_ct": bstr .size 1120,
  "wrap":   bytes48,
}

passphrase-block = {
  "alg":    kdf-alg,
  "salt":   bstr .size (16..64),
  "params": { "m": uint32, "t": uint32, "p": uint32 },
}

; A signature entry is a closed map. `cose_sign1` is REQUIRED and carries the
; CBOR-encoded COSE_Sign1 as a single byte string; `cose_key` is OPTIONAL and
; carries the CBOR-encoded COSE_Key for the wallet-signing path as a single
; byte string.
sig-entry = {
  "cose_sign1":  bstr,
  ? "cose_key":  bstr,
}

; A uri is one absolute URI in a single text string. The URI shape rules
; (absolute, no fragment, closed scheme set {ar://, ipfs://}) are enforced in
; the typed pass; the rule carries no length cap.
uri = tstr

bytes32 = bstr .size 32
bytes48 = bstr .size 48

; uint32 is the pinned range of every numeric field: an unsigned integer
; representable in 4 bytes (0 .. 2^32-1), handled as an exact integer.
uint32 = uint .size 4

; Algorithm-identifier strings are open `tstr`: the registries are
; authoritative for accepted values, and the typed pass emits the precise
; unsupported-algorithm code for any unrecognised identifier.
content-hash-alg   = tstr  ; e.g. "sha2-256", "blake2b-256"
merkle-commit-alg  = tstr  ; e.g. "rfc9162-sha256"
aead-alg           = tstr
kem-alg            = tstr
kdf-alg            = tstr

関連ページ

• コンテンツとハッシュ化 — hashes マップ、ダイジェストがコミットする対象、そして正確なバイト列のセマンティクス。
• アルゴリズムレジストリ — ハッシュ、リストコミットメント、AEAD、KEM、KDF の名前付き識別子。
• 署名 — レコードレベルの sigs の構造と検証。
• 封緘済み PoE — enc エンベロープと受信者鍵スロット。
• 検証 — 検証パイプライン、CID プロファイル、エラーカタログ。