耐量子化への移行
2026-09-12 時点では、署名・鍵交換のハイブリッド実装と、commitment・証明・決済状態まで対象にする PQC 研究を区別する。新規ネットワーク上で限定した証明と状態更新を実行したが、実用 note と市場全体の PQC 化は未完成である。既存台帳の移行は対象にせず、既存環境を保持する。
証明・新規ネットワークの実装記録 · PQC note の実装範囲 · 2026-09-12
加法準同型の代わりに、秘密の計算関係を証明する
PQC note の方針は、秘密の数量と乱数を SHA-512 で commitment にし、その開封関係と決済の計算を証明することである。ハッシュ自体に加法準同型性はない。説明用に C0 = H(v0 || r0)、C1 = H(v1 || r1)、C2 = H(v2 || r2) と書けば、秘密の入力についてこれらの等式、v0 = v1 + v2、数量の範囲を同時に証明する。実際の形式はドメイン、配備方針、資産、所有権も結び付ける。
DeFMI は公開 commitment と証明を受け取り、正規台帳の入力、支出権限、nullifier の未使用、出力との関係を検証して状態を更新する設計である。単に開封をサーバーへ渡してハッシュを照合する処理では秘匿証明にならない。ハイブリッド署名を付けるだけでも、Pedersen の束縛や note 証明の耐量子化にはならない。
実行済みの研究と未完成の実用経路
- 実行済み:ハッシュ・符号・sumcheck に基づく協調証明。7 者の所有者別入力で限定した 4 口座の算術関係を証明し、独立した公開データだけの検証器で確認。暗号化入力の実験では、約定・非約定と復旧を含む 740 の正規 Block/State 遷移を記録した。別の新規ネットワーク実験では、1 ホスト上の 5 検証者で受理と再起動後の状態一致を観測した。
- 実装途中:新しい PQC note の形式、受取人だけが持つ支出鍵、ハイブリッド暗号化による配送とウォレット内の復号。完全な note の秘密計算関係、特に出力暗号化の証明、匿名の所属・支出、予約・約定・返却を結び付ける実用経路は未完成である。
- 判定:実行した研究は
smoke_only。独立運営者による保管、実際の QOMM/OCLOB 入力からの全経路、構成全体のゼロ知識性・量子攻撃に対する健全性・具体的安全性パラメータの外部検証は残っている。
ハイブリッド導入時の記録: 2026-09-06〜2026-09-08
| 項目 | 状態 | 根拠 |
|---|---|---|
基盤 crate zkfmi-crypto（P0） | 実装済み · ゲート通過 | Linux ホスト 1 台、公式の Rust 1.97 イメージ上で fmt、strict clippy、release テストを通した。テストは 45 本で、NIST ACVP のテストベクタ 8 本と RFC 8032 の検査を含む |
| 7 リポジトリの暗号使用箇所の棚卸し（P0） | 完了 | 507 ファイル、暗号プリミティブの項目 1,032 件。独立に行った grep と照合し、欠落 0、余剰 0 |
| QOMM、zkPI、DeFMI、OCLOB、DeKYX、DeCCP、Aethel にわたる P1 から P6 の統合 | main で受入済み · ホスト 1 台 | ネイティブ実行を 2026-09-06（exit 0、15 分 07 秒）と 2026-09-07（零関係の開封証明の修正を取り込んだ後、PASS）に行った。シナリオは市場、finality、lifecycle、P6 復旧。各実行の前後でソースのハッシュが一致 |
リリース rev の固定、lock 再生成、ゲート再実行、main への統合 | 完了 · 2026-09-07 | 通信、MPC エンジン、監査、DSL、シミュレータ、計測の各 crate を zkPI に移し、DeFMI ⇄ QOMM の依存の循環を断った。各リポジトリは他のリポジトリを不変の git rev で固定し、隣の checkout を重ねる overlay は使わない。9 ワークスペースすべてが lock 固定の検査を通り、固定後の配置でネイティブ受入も通った。8 つの main がすべて受入済みの状態を持つ。全体構成ページを参照。 |
| ゼロ知識の関係式（commitment、範囲証明、ring、quote proof、FROST） | 古典 | 既存経路の分類。別の PQC 証明研究は上記を参照 |
| 性能比較 | 計測済み · 1 ホスト · 2 回 | 基本演算は 2026-09-07 に、公開していた OCLOB の画像で端から端までを 2026-09-08 に計測。最初のハイブリッド画像は注文 1 件あたり、板に残る注文で +56 ms、約定する注文で +74 ms（中央値）。エンジン受領証の検査をプロセスごと 1 回にし、7 プロセスを回をまたいで維持したあとは、ハイブリッド画像が従来版より 177 ms と 202 ms 速い。詳細は下 |
| 独立した運営者、WAN、HSM、FIPS 認証、外部監査 | なし | 受入記録は、これらをいずれも未実施と記している |
基盤: zkfmi-crypto
他のすべてのリポジトリが、git rev を固定して依存する crate が一つある。この crate は語彙（スイート名や鍵の種類）と、それらの組み合わせ方を定める。各サービス自身の鍵保管や、DeKYX の発行者 epoch（鍵の世代）を置き換えるものではない。それらに共通の形を与える。
- スイート識別子。一覧は閉じていて、版が付く。使用中の古典スイート（Ed25519、ristretto255 上の FROST、ristretto255 上の Pedersen と Bulletproofs、TLS 1.3 の X25519、SHA-256/512、SHAKE128）、耐量子スイート（ML-KEM-768、ML-DSA-65、ML-DSA-44、SLH-DSA-SHA2-128s）、ハイブリッド（X25519MLKEM768、Ed25519+ML-DSA-65）を含む。各スイートは用途とバイト長を持ち、テストで FIPS 203/204/205 の定数と照合する。未知のスイートや版は拒否する。既定値に読み替えることはない。
- 正規化した署名入力。署名の対象となるバイト列の並べ方を一つに決めたもの。プロトコル、版、ネットワーク、配置、契約、トランザクション種別、オブジェクト識別子、シーケンスまたは nonce、期限、スイート、本文ハッシュを、それぞれ固定幅整数の長さ接頭辞を付けて、ドメイン
ZKFMI:CANONICAL:v1の下に並べる。期待値となるバイト列（golden ベクタ）は hex で固定してある。同じ本文でも用途が違えば署名の入力が変わる。したがって、ある用途の署名を別の用途に流用できない。 - 用途に束縛した鍵。鍵レコードには、参加者、用途（見積、決済指図、鍵の交代、統治、トランスポート、attestation）、スイート、世代、有効期間、失効、交代の証明を書く。鍵の交代は双方向に署名する。旧鍵が新鍵に署名し、新鍵が旧鍵の識別子に署名する。
- ハイブリッド署名。同じ正規化入力に対して、Ed25519 と ML-DSA-65 の両方で署名する。検証は両方が通ったときだけ受理する。片方が失敗、片方が欠落、二つが入れ替わっている、のいずれも拒否する。ML-DSA のコンテキスト文字列には用途とスイートを入れる。
- ハイブリッド鍵交換。X25519 と ML-KEM-768（KEM、鍵カプセル化: 公開鍵で共有秘密を包んで送る仕組み）を、それぞれ独立に生成した秘密で動かす。両方の共有秘密、両方の暗号文、スイート識別子を HKDF-SHA256 に通して一つの鍵にまとめる。どちらの半分を差し替えても導出される鍵が変わることを、テストで確かめている。
- バックエンド。RustCrypto の
ml-dsa0.1.1 とml-kem0.3.2（純 Rust、Apache-2.0 OR MIT）を使う。バイト指向のトレイトの背後に置いてあるので、aws-lc-rs のような FIPS 認証済みのバックエンドに後から差し替えられる。古典側は ed25519-dalek 2.2 と x25519-dalek 2.0。#![forbid(unsafe_code)]を指定し、秘密はメモリから消去（zeroize）する。この選択は工学上の選択であり、本番・監査・FIPS の主張ではない。
バイト数はどれだけ増えるか
| 方式 | 公開鍵 | 署名または暗号文 |
|---|---|---|
| ML-KEM-768 | 1,184 B (dk 2,400 B) | 1,088 B |
| ML-DSA-44 | 1,312 B | 2,420 B |
| ML-DSA-65（採用） | 1,952 B | 3,309 B |
| ML-DSA-87 | 2,592 B | 4,627 B |
| SLH-DSA-SHA2-128s | 32 B | 7,856 B |
3-of-7 の承認に必要な ML-DSA-65 署名 3 本で 9,927 B になる。古典スタックで計測した決済パッケージの大きさは、口座レールの実行で 57,971 B、64 ビットのレールでの Bulletproofs で 3,424 B である。これに対して、追加の署名は支配的な項ではない。ただし、計画にある暫定の目標 16 KB と上限 32 KB は、すでにそれを超えるパッケージ定義を前提に書かれている。定義を確定した後に再設定する。ポリシー更新の経路では、ML-DSA-65 のバイト数は Ed25519 の約 15× になる。実際のマーケットメイカーが使う頻度でも、毎秒 3 メガバイト未満である。所要時間は次の節で計測値を示す。
所要時間はどれだけ増えるか
2026-09-07 に、ビルドホストの x86-64 の 1 コアで計測した。スタックが実際に使う署名・検証・KEM の trait を通し、ウォームアップの後に操作ごとに 300 回測り、メッセージは 256 バイトである。ベンチは zkfmi-crypto の examples/pqc_bench.rs。実行前に書いた予測、実行の受領証、予測が外れた箇所の検討は docs/PQC_PERFORMANCE_2026-09-07.md にある。値は中央値で、実行は 1 回である。
| 操作 | Ed25519 / X25519 | ML-DSA-65 / ML-KEM-768 | ハイブリッド | ハイブリッド : 古典 |
|---|---|---|---|---|
| 署名鍵の生成 | 12.2 µs | 221.9 µs | 238.1 µs | 19.5× |
| 署名 | 13.6 µs | 340.2 µs | 359.3 µs | 26.4× |
| 検証 | 38.4 µs | 126.8 µs | 173.7 µs | 4.5× |
| KEM 鍵の生成 | 11.9 µs | 38.6 µs | 51.0 µs | 4.3× |
| カプセル化（encapsulate） | 48.9 µs | 37.0 µs | 88.1 µs | 1.8× |
| 開封（decapsulate） | 37.0 µs | 40.4 µs | 79.6 µs | 2.2× |
ハイブリッド署名は、1 コアで作るのに 0.36 ms、確かめるのに 0.17 ms かかる。決済 1 件の端から端までは数十ミリ秒から数秒の単位で計測されているので、基本演算だけでは遅延に現れない。経路全体で何 ms 増えるかは次の節で測る。通信路では、移行はバイト数に現れる。署名付きの対象はどれも、署名 1 本あたり 3,309 B、埋め込む公開鍵 1 つあたり 1,952 B 大きくなる。1 コアあたりの検証処理量は、毎秒約 26,000 件から約 5,800 件に下がる。カプセル化と開封は受取人向け封筒のすべてが通る経路だが、2 倍にはならない。ML-DSA-65 の署名には長い裾がある。中央値 340 µs に対して p90 は 951 µs で、これは標準が定める棄却サンプリングによる。ハイブリッドの各行は、二つの構成要素の和に 5 µs 以内で一致する。ベンチが出した大きさは、上の表とすべての行で一致した。
注文 1 件の所要時間はどれだけ増えたか
2026-09-08 に、空いている 64 コアのホストで、公開デモの OCLOB を動かしてきた二つの画像を並べて測った。2026-09-07 まで公開していた従来版（MP-SPDZ 標準の TLS、RSA-2048 証明書、アプリ署名は Ed25519）と、それ以降のハイブリッド版である。準備の 2 回のあと各画像 20 回、1 回ごとに画像を交互に切り替えた。1 回は、板に残る maker の売り注文と、それを全量約定させる taker の買い注文の組である。予測、実行、検討は zkfmi-crypto の docs/PQC_E2E_LATENCY_2026-09-08.md にある。計測は一回である。
| 注文の種類 | 従来版の中央値 | ハイブリッド版の中央値 | 増分の中央値 | 増分の p95 |
|---|---|---|---|---|
| 板に残る maker 注文（約定なし） | 1,211.6 ms | 1,268.0 ms | +56.4 ms（+4.7%） | +16.3 ms |
| 約定して決済まで進む taker 注文 | 1,707.2 ms | 1,781.0 ms | +73.8 ms（+4.3%） | +76.3 ms |
| 板に残る maker 注文、常駐の実行器にしたハイブリッド版（同日の 2 回目） | 1,195.5 ms | 1,018.5 ms | −177.1 ms（−14.8%） | −229.1 ms |
| 約定して決済まで進む taker 注文、常駐の実行器にしたハイブリッド版 | 1,707.2 ms | 1,505.4 ms | −201.8 ms（−11.8%） | −196.3 ms |
増えた時間の内訳。注文ごとに 7 つの MP-SPDZ プロセスを起動し直し、各プロセスは相互認証つきの TLS 接続を 12 本張るので、1 回で 42 回のハンドシェイクが起きる。同じ OpenSSL 3.5.5 でループバック上のハンドシェイク 1 回を測ると、従来版が使っていた RSA-2048 証明書で 1.07 ms、Ed25519 証明書で 0.56 ms、ML-DSA-65 証明書と X25519MLKEM768 で 2.19 ms だった。OpenSSL 3.5.5 の ML-DSA-65 署名は 1 回 0.69 ms で、これが最も大きい項であり、1 回あたりおよそ +13 ms になる。ハイブリッド版はさらに、45 MB のエンジンのバイナリを毎回読み直して .pqc-tls.sha256 の受領証と照合しており、これに約 35 ms かかる。この検査は移行で加えたもので、MPC の計時が始まる前に動く。ハイブリッドのアプリ署名（計画 1 件、参加者の受領証 7 件、ノードの受領証 1 件、遷移の証明 5 件、3 ノードの定足数）は見積もりで 10〜20 ms を足す。残る 30〜40 ms は暗号以外のビルド差で、今回は分けていない。
計画の目標に対して。この経路の処理量は従来の 95.5% と 95.9% で、目標の 95% を半ポイント上回る。追加の遅延は p95 で 16 ms と 76 ms で、目標の 5 ms を満たしていない。実行前に書いた予測は差を −10〜+5 ms と見ていて、二つの点で外れた。エンジン受領証の検査を起動時の 1 回だけと思っていたこと、ML-DSA-65 の署名が RSA-2048 の署名より速いと見ていたことである。OpenSSL 3.5.5 では 0.69 ms 対 0.27 ms で逆になる。この二つは同じ日のうちに直した。エンジンのバイナリはプロセスごとに 1 回だけハッシュし、回ごとにはファイルの識別情報で確かめる。デモの実行器は 7 つのプロセスを回をまたいで維持し、各回の入力を名前付きパイプで渡す（ネイティブ受入の 7 プロセス構成は今も回ごとに起動する）。表の 2 回目の行がその結果で、ハイブリッド画像は従来版より注文 1 件あたり 177 ms と 202 ms 速くなり、計画の目標は二つとも、公開していた従来版に対して満たした。同じ実行器を載せた従来版なら、ハイブリッドのアプリ署名の分だけ、見積もりで 10〜20 ms さらに速いはずである。実行前に書いた予測はもっと大きな短縮（1 回あたり 300 ms 以上。実測は 250 と 276）を見込んでいて外れた。プロセスの起動、接続の確立、受領証のハッシュで約 250 ms、残る 500 ms は回路そのものの前処理とオンライン段階で、MP-SPDZ はこれをループの中でも回ごとに生成する。
計画と、各フェーズの現在地
| フェーズ | 対象 | main で確認したこと |
|---|---|---|
| P0 棚卸しと基準値 | 暗号を使うすべての箇所の機械可読な一覧。各形式にスイート、鍵、版のフィールドを追加。基準値を計測 | 棚卸しは完了。基盤 crate はゲート通過。古典の基準値は、引き続き計測値のページの値を使う |
| P1 トランスポート | 常設接続のすべてでハイブリッド鍵交換。注文ごとの KEM はしない。古典方式への降格は拒否 | QOMM、OCLOB、DeFMI の接続は TLS 1.3 を要求する。鍵交換は X25519MLKEM768、証明書の鍵とチェーンの署名は ML-DSA-65 で、トラストアンカー（信頼の起点となる証明書）も含む。MP-SPDZ のソケットアダプタも、同じグループ・版・署名の許可リストをホスト名検証付きで強制する。チケットとセッションキャッシュは無効にした。OpenSSL 3.5 を vendor（同梱）し、ベースイメージは変えない。note の開封値を受取人へ届ける封筒は、ハイブリッド KEM と AES-256-GCM を使い、受取人、用途、スイート、版に束縛する |
| P2 指図と決済承認 | zkPI の発行、および予約・約定・取消の承認へのハイブリッド署名 | 実行の wire 形式（通信で送るバイト列の形式）に型と版を付けた。勝者への封筒は、名簿に固定した Ed25519 と ML-DSA の署名を、同じ本文に対して要求する。ネイティブ決済は、登録済みのノード別 ML-DSA 承認を要求し、定足数と名簿を厳密に検査する |
| P3 DeKYX | 発行者の署名、状態一覧、保持者の所持証明 | 登録済みのハイブリッド認可。保持者側の保管は暗号化。保持者の所持鍵は独立。旧形式のスナップショットは fail-closed（読めなければ拒否） |
| P4 DeCCP、保証、担保、ドメイン間 | 統治、清算の承認、保証枠、finality の受領証 | 統治、参加者、提供者、保証人/CSD、DeCCP、ドメイン間、Aethel の各権限経路は、登録済みのハイブリッド鍵を使う。OCLOB の参加者は、独立した一回限りの請求鍵を持つ |
| P5 公開監査証明 | 公開するものに対する耐量子のゼロ知識証明 | 範囲は狭い。STARK（Miden 0.32、本家の alpha 版、未監査）が証明するのは、公開ルートの連続性、settled フラグ、固定スロット内の受領証と zkPI ダイジェストのコンテキストである。隠された値付け、保存、匿名の関係式は証明しない |
| P6 退役と復旧 | 古典鍵の退役、アーカイブからの復旧、リプレイ | チェックポイントの来歴、鍵の退役、アーカイブからの復旧、乱数を含む受領証の厳密なリプレイを、決定的ゲートとネイティブゲートで動かした。古典スイートそのものの退役はまだ行っていない |
ネイティブ受入で動かしたもの
8 リポジトリすべてのソースを一つのスナップショットに凍結した（1,119 ファイル、実行の前後でハッシュが一致）。これを Linux ホスト 1 台で固定イメージにビルドし、その上で次を動かした。ハイブリッド TLS アダプタ上の MP-SPDZ プロセス 7 つ、DeFMI の L1、OCLOB のメイカー API とテイカー API。4 つのシナリオが順に通り、合計 15 分。
- 市場: 3 ラウンド。自律決済 2 件、耐量子の応答署名 4 本、一回限りの鍵 8 本。応答を失った後の復旧。重複決済はゼロ。
- finality: 署名付きの秘匿状態の受領証が、同じプロセス内の再試行、再オープン後、別プロセスからのいずれでも、バイト単位で同一に返る。二重適用は拒否。7 ノードの正規化された観測。差し替えは拒否。ウォレットの再オープン。請求 3 件。秘匿保証枠の witness（証明の秘密入力）2 件を復旧し、次の注文で消費。
- lifecycle: 約定 3 件、新しい耐量子鍵 12 本、応答署名 6 本。部分約定の後に順序付きで取消し、厳密なリプレイと再起動を含む。期限切れによる解放。7 ノードの再起動チェックポイント。
- P6 復旧: 新たに解決した不変な依存関係の下での復旧テスト 2 件。
この実行で欠陥が 2 件見つかり、通過前に修正した。一つは、再試行ごとに ML-DSA 署名を作り直していた受領証で、署名済みの受領証を永続化して再送するようにした。もう一つは、部分約定の後に返金の開封値が新しい操作識別子で再認可されていたもので、元の請求コンテキストを保持するようにした。補助ゲートは次のとおり。OCLOB のテスト 125 件、zkPI・DeKYX・DeCCP・P5 の各ワークスペースにわたるテスト 279 件、QOMM のトランスポートとデモのテスト、Aethel のエンドツーエンド。すべて strict clippy 付き。
既存の古典経路と新規 PQC 研究の境界
既存の Pedersen・Bulletproofs・Triptych・FROST 経路は離散対数に依存し、新しい資産 ID 秘匿の Ristretto 経路も PQC On では拒否する。PQC 研究では SHA-512 と符号ベースの証明を使い、BN254 は算術の体としてだけ使う。楕円曲線 commitment、ペアリングの最終証明、委員会署名を証明の健全性の代わりに使う構成ではない。これでも、実装した構成全体の耐量子安全性が確立したことにはならない。
根拠の限界
- ホスト 1 台、管理者 1 人。独立した運営者、WAN、物理 HSM はない。
- バックエンドの FIPS 認証も外部監査もない。
- 性能比較は、空いている 1 台のホストで、公開していた OCLOB の二つの画像をループバック上で 1 回測ったものである。計画の処理量の目標（基準値の ≥95%）は半ポイントの差で満たす。遅延の目標（p95 のオーバーヘッド 5 ms）は満たしていない。p95 で、板に残る注文は +16 ms、約定する注文は +76 ms である。7 プロセスのネットワーク障害テストは、7 ノードの WAN の根拠にはならない。
- P5 の証明器は本家の alpha 版（Miden 0.32）に依存し、意図的に狭い命題を証明する。