未解決の論点

Label 309 v1 は凍結済みです。メタデータラベル309のもとでのワイヤーフォーマット、 正規 CBOR エンコーディング、アルゴリズムレジストリ、封緘済みの存在証明（Proof of Existence, PoE）のエンベロープ、そして署名構成はいずれも確定しています。v1 準拠の検証者はあらゆる v1 レコードを 読み取り、v1 準拠の生成者はあらゆる v1 検証者が受け入れるレコードを出力します。 このページの目的は、それを変更することではありません。ここは、今日の標準で何が確定しているか、 そして何が将来構想として残っているか、すなわち将来のリビジョンに向けて予約された候補の暗号構成と、 そのいずれかが採用された際に暗号定数を規律正しく変更するための手順を記録した一覧です。

ここに記載された内容は、いずれもプロダクトのロードマップではありません。各項目はプロトコルレベルの 技術的決定、すなわちアルゴリズム識別子、導出、検証者ポリシー、あるいはバージョニング規則です。 標準を実装する読者は、今日 v1 実装を構築するために確定した部分を必要とし、 将来のポスト量子あるいは RFC のみの後継が、書き直しではなく追加的なレジストリ登録で済むように 実装するために、将来構想の部分を必要とします。

確定した構成

これらは決定済みです。実装者がひとつの場所で確認したいと最も望む、骨格となる選択であるため、 ここで端的に述べておきます。完全な構成はリンク先の各ページに記載されています。

ポスト量子 KEM は v1 で出荷される

ハイブリッド KEM である X-Wing（ML-KEM-768 を X25519 と組み合わせたもの）は、 最初のリリースから enc.kem レジストリにおいて識別子 mlkem768x25519 として登録されています。 これは将来の候補ではありません。古典的な x25519 KEM と並んで enc.scheme: 1 に存在し、 オンワイヤーの enc.kem フィールドが、レコードごとにスロット単位の KEM、スロット形状、 鍵暗号化鍵の導出を選択します。

X-Wing はブラックボックスとして消費されます。構成はその公開インターフェース、すなわちカプセル化・ 脱カプセル化・32 バイトの共有秘密だけを使い、コンバイナー内部のハッシュについては何も仮定しません。 どちらの KEM も、スロット自身のワイヤーバイト列に対して計算される一つのラベル付きハッシュのソルトの形 SHA-256(label || enc.nonce || <スロットの KEM 素材> || pub_R) のもとでスロット単位の KEK を導出します。 ハイブリッドの経路では SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R) です。 固定長の 32 バイトへハッシュすることで、エンベロープの nonce、暗号文、受信者の公開鍵を KEK へ結合すると同時に、 可変長のポスト量子暗号文が素朴な連結ソルトのもとで生むであろうパーサーの曖昧さを解消します。 公開されているのはハイブリッド版のみです。純粋な ML-KEM はあえて非公開とし、 仮に ML-KEM-768 が破られても X25519 のレッグが古典的安全性を保てるようにしています。 封緘済み存在証明 および アルゴリズムレジストリ を参照してください。

封緘の鍵コミットメントはヘッダーとハッシュ主張を結合する

封緘の両経路とも、コンテンツ暗号化鍵を閉じたトランスクリプトにコミットします。これはエンベロープの他の部分が 使うのと同じ正規 CBOR 関数でシリアライズされ、ヘッダーフィールドとアイテムの平文ハッシュ主張（hashes_hash）を 固定します。受信者宛て（enc.slots）の経路では、このコミットメントはオンチェーンにあります。slots_mac は、 スキーム・パス・AEAD・KEM の各識別子、nonce、シャッフルされたスロット集合、そして hashes_hash を収めた トランスクリプトに対する CEK 鍵付き HMAC です。そのため、リレーが暗号文を別のスロット集合や別のハッシュ主張へ 継ぎ接ぎしようとしても、暗号文を取得する前に、オンチェーンの MAC チェックが失敗します。パスフレーズ （enc.passphrase）の経路は、Argon2id のソルトとパラメータを加えたトランスクリプトに対する同等のコミットメントを、 暗号文ブロブの内側にある 32 バイトのヘッダーに収めます。これにより KDF の入力を改ざんすると、コミットメントの チェックが失敗します。コンテンツそのものは、その後、CEK から導出したコンテンツ鍵のもと、セグメント化された STREAM で封緘されます。チャンクごとの AAD は空です。すべてのヘッダーフィールドが、すでに推移的にその鍵へ 結合されているからです。完全な構成は 封緘済み存在証明 に記載されています。

確認深度は検証者ポリシーである

レコードはそのトランザクションが取り込まれた瞬間にチェーン上に記録されますが、 判定を報告する前にどれだけの決済を求めるかを決める検証者は、確認深度のしきい値を適用します。 Label 309 はこれを規範的な MUST ではなく、検証者ポリシーと位置づけます。 標準が定義するのは機械可読な表面です。すなわち、しきい値を下回るトランザクションは pending （型付きコード INSUFFICIENT_CONFIRMATIONS）として報告され、決して failed にはならず、再試行で valid に 解決し得ます。一方でしきい値そのもの（推奨は 15 ブロック以上）は、 ワイヤーフォーマットに焼き込まれた定数ではなく、デプロイ時に設定される入力です。 高額な主張に対してより深い決済を求める検証者も、完全に準拠しています。 検証 を参照してください。

Ed25519 の検証は厳格である

レコードレベルの署名は、より寛容な ZIP-215 のバッチ検証許容ではなく、 RFC 8032 §5.1.7 の厳格な規則のもとで 検証しなければなりません（MUST）。厳格な検証は、寛容な検証者であれば受け入れてしまう 非正規エンコーディングや小位数の点を拒否します。そのため、二つの準拠検証者は同一の署名に対して 常に同一の判定に到達します。実装者は、自らの Ed25519 バックエンドが厳格モードであることを 確認しなければなりません。ライブラリによっては、既定で寛容な変種を用いるものもあります。 署名 を参照してください。

正規 CBOR が決定性の契約である

すべてのレコードは RFC 8949 §4.2.1 に従った正規 CBOR としてエンコードされます。すなわち、整数は優先形式、配列とマップは確定長、 マップのキーはバイト単位でソート、重複キーなし、タグなしです。決定性こそが、 ある実装が本体に対して計算した署名を別の実装が検証できること、そして同一の論理レコードを生成する 二つの生成者がバイト単位で同一のバイト列を出力できることを可能にします。これはあらゆる準拠実装を通じて 妥協の余地がなく、言語をまたいだパリティ契約の基盤です。

将来構想の候補

以下の項目は候補であり、出荷された構成ではありません。いずれも v1 の欠陥ではなく、 いずれも確約されていません。これらが記録されているのは、今日構築される実装が、それらを追加的なレジストリ登録として 受け入れる余地を残せるように、そして将来のレビュアーが、アルゴリズム俊敏性（アルゴリズムを差し替え可能）の設計が すでにどの進化を見込んでいるかを把握できるようにするためです。

予約された代替のコンテンツ AEAD プロファイル

v1 の封緘済み存在証明のコンテンツ層は chacha20-poly1305-stream64k、すなわち RFC 8439 の ChaCha20-Poly1305 をセグメント化した STREAM レイアウトに したものです。これ自体が RFC に裏付けられているため、現在のコンテンツ暗号の形式的な位置づけについて未解決の問いは ありません。予約されたまま残っているのは、いずれかのデプロイ環境がそれを必要とした場合に、別のコンテンツ AEAD へ 至る道です。識別子 aes-256-gcm（NIST SP 800-38D）は、その目的で AEAD レジストリに予約されており、enc.scheme: 1 の一部ではありません。これを指定したレコードは、今日のところ 未知のエンベロープのルールに従います。

これを導入するとすれば、それは将来の enc.scheme: 2 構成であり、既存の slots[] + slots_mac モデルと パスフレーズのコミットメントモデルを保ちつつ、コンテンツ層を差し替え、その暗号に向けた新たなチャンクサイズ、 コンテンツ鍵の導出、チャンクごとの nonce 構築、チャンクごとの AAD、そして最終チャンクの認証を固定します。 これは置き換えではなくフォールバックプロファイルです。既存の enc.scheme: 1 レコードは 有効なままであり、このプロファイルは規範的な enc.scheme: 2 の定義とそのテストベクトルが存在する前に 実装してはなりません。

予約されたポスト量子署名アルゴリズム

ポスト量子への道筋のうち KEM の側は v1 で出荷されます（上記）。署名の側は予約されているものの、 まだ実装されていません。IETF COSE がポスト量子の アルゴリズム識別子を安定化させ次第、既存の署名レジストリに収まる候補として、二つのファミリーがあります。

署名アルゴリズムは COSE の保護ヘッダー内の名前付き識別子であるため、後継の登録は純粋に追加的です。 既存の Ed25519 レコードは検証され続け、新しい署名アルゴリズムを認識しない検証者は、コンテンツの主張を 拒否するのではなく、サポート外アルゴリズムの信号を報告します。認識されない署名が、根底にある存在証明を 無効にすることは決してありません。署名 を参照してください。

将来的な v: 2 の発行経路

個々の追加、すなわち新しい KEM、新しいコンテンツ AEAD、新しい署名アルゴリズムは、トップレベルのレコード スキーマを変更しないレジストリ登録です。とりわけ KEM の追加は、スキームのバンプではなく enc.scheme: 1 のもとのレジストリ登録です。enc.scheme のバンプは、KEM をまたぐ構成変更 （あらゆる KEM に一度に適用される新しい slots_mac あるいはコンテンツ AEAD）のために予約されています。

レコードスキーマを変更する候補が十分に蓄積した場合、その累積的な変更は、v1 と並べて発行されるトップレベルの v: 2 レコードを正当化しうります。両バージョンともラベル309のもとで有効なメタデータスキーマであり続け、 検証者はレコード内の v 識別子によって選択します。標準化への道筋の各ステップは、新しいリビジョンに対して 繰り返されます。これは最も影響範囲の広い進化であり、蓄積によってのみ引き起こされます。ここに予定されたものは 何もありません。

任意の一段の上書き解決

レコードの任意の supersedes フィールドは、トランザクションハッシュによって、より古い一つのレコードを指します。 そのポインタを解決するかどうかは、検証者にとって任意です。supersedes が構造的に 32 バイトのハッシュ値で あることを確認しつつも、先行するトランザクションを取得しない検証者も準拠していますが、上書きの連鎖を提示する機会を 逃すことになります。指針として、検証者は一段だけ解決してもよく（MAY）、すなわち参照されたハッシュについて トランザクションリゾルバに再問い合わせし、その存在とブロック時刻を報告できますが、それ以上は再帰しません。 一段で十分であり、それより深い辿りは呼び出し側の責任です。そして上書きは先行するレコードを取り消すことは決してなく、 そのレコードはチェーンが独立に検証可能な状態で永久に保持し続けます。

暗号定数の移行

上記の確定した構成はいずれも、名前付きの定数、すなわちアルゴリズム識別子、HKDF info 文字列、KDF ソルト、 AEAD nonce 長、ドメイン分離ラベルに依存します。そのいずれか一つの意味を変えることはワイヤーフォーマットの 破壊であり、標準はそのためのただ一つの規律ある道筋を定めています。その統べる規則は次のとおりです。 問題を解決する最小範囲の変更を用い、同一の名前空間のもとで既存の定数の意味をひそかに変更してはならない。

その手順は追加的かつ後方互換的です。古いレコードは、それが発行された際の定数のもとで検証され続けます。 そして範囲に応じて、次のように進みます。

1. 値ではなく名前空間をバージョン付けする。 導出が変わった場合、それが触れるあらゆるドメイン分離文字列の -vN サフィックスをインクリメントします。すなわち HKDF info 文字列（…-v1 → …-v2）、HMAC のメッセージ プレフィックス、ソルト、ラベルです。新しい定数は新しいサフィックスのもとに存在し、古い定数は古いサフィックスの もとで有効なままです。より古い検証者は、新しいレコードを誤って解釈するのではなく、識別子の段階できれいに拒否します。

2. 影響範囲に見合った識別子をバンプする。 一つのスロットファミリーに限定された変更は enc.kem によって 選択されます。コンテンツ層あるいはスロット集合のコミットメントに対する KEM をまたぐ変更は enc.scheme の バンプです。レコードスキーマそのものの変更はトップレベルの v のバンプです。各識別子は、破壊を実際に変わった 最小の層に局所化します。

3. 先行物を検証可能に保つ。 より古いレコードバージョンは、凍結されたスキーマとして読み取り可能なままです。 検証者はレコード自身のバージョン識別子によって構成を選択するため、単一の実装が v1 と将来の後継を並べて 検証できます。後継が出荷されたことを理由に、検証されなくなるレコードは一つもありません。

関連ページ

• アルゴリズムレジストリ — 移行のもとで名前空間がバージョン付けされる、 名前付きの識別子。
• 封緘済み存在証明 — X-Wing ハイブリッド KEM、鍵コミットメントのトランスクリプト結合、そして enc.scheme / enc.kem の識別子。
• 署名 — 厳格な Ed25519 検証と、予約されたポスト量子アルゴリズムが加わることになる 署名レジストリ。