zkFMI
English

今後の計画

現状文書、用途調査、ポジションペーパーの未解決の問いから項目を集め、順に並べた。日付は書いていない。約束した日付が一つもないからである。項目は、いつ起きうるかではなく、何に依存するかで分けた。

更新: 2026-09-12。非 PQC の note は現在 Triptych 系の所属証明と加法準同型 commitment を使う。資産 ID 秘匿の native 経路を実行し、新規ネットワークのハッシュ・符号ベースの PQC 証明研究も進めている。実用 PQC note と全市場経路の完成は別の未解決課題である。以下の過去の測定は元の方式と環境に属する。 note の実行証跡 · PQC の現在地

完了し、受入済みのもの

  • Rust によるプロトコル中核、計測済み

    閾値範囲証明と固定テストベクタを備えた zkPI v2。DeFMI の口座、note、tag、ネッティング、限度、ウォーターフォール、PvP、照合、scope 付き閲覧、審査証明（vetting）。Bulletproof バックエンド。DeKYX、DeCCP、Aethel の crate ワークスペース。

  • 検証者 5 台のネイティブ Avalanche L1、ホスト 1 台

    複数 RFQ の原子的決済、リプレイ拒否、再起動からの復旧、状態 root の合意。QOMM の経路では、7 つの MP-SPDZ プロセスから追加の署名なしに決済する。

  • OCLOB から L1 への分散経路、ホスト 1 台

    参加者側での注文の分割、7 コンテナへの暗号化した直接配送、5-of-7 の到着証明書、MPC による照合、メイカー予約とテイカー予約、再起動とリプレイの検査を含む DvP。

  • 束縛と説明責任の仕組み

    MPC の体を commitment の群の位数に合わせた構成（matched field）、通信量は 2.00×。参加者ごとの健全な入力検査。誤った share の位置を特定するデコーダをエンジンに組み込んだ。n=9 での頑健な復元を 2 台の計算機で計測した。

  • 記録に残る 2 回のレビュー

    健全性の指摘は修正して文書化した。撤回した主張は一覧にした。外れた予測もそのまま残した。

  • 耐量子化の統合を main に載せる

    8 リポジトリすべてで、Ed25519 + ML-DSA-65 のハイブリッド署名と X25519 + ML-KEM-768 の鍵交換を入れた。これが 2026-09-06 に単一ホストのネイティブ受入を通過した。2026-09-07 には零関係の開封証明（値の部分が 0 であることの証明）の修正を取り込んで、再び通過した。同日、スタック側の crate を zkPI へ移して DeFMI ⇄ QOMM の循環依存を断った。各リポジトリは不変の rev で固定され、8 つすべてが main にある。オーバーヘッドは 2026-09-08 に、配置済みの OCLOB イメージ 2 つで計測した。runner の常駐化と、受領証の検査をプロセスごとに 1 回にする変更の後、ハイブリッド版のイメージは古典版より注文 1 件あたり 177 ms および 202 ms 速い。耐量子化への移行を参照。

次にやること、依存関係の順に

  • OCLOB の決済権限の閾値化

    現在は研究用のゲートウェイ 1 台が、参加者の固定長の決済権限を単独で開いている。これを、MPC ノードによる閾値復号か zkPI の共同生成に置き換える。OCLOB を実資産に使えなくしている P0 項目である。

  • 資産 ID 秘匿の note と市場を接続する

    新しい native 経路では発行、予約、部分約定、返却、受領権償還と再起動後の復旧を実行した。次は既存の QOMM/OCLOB 呼出しを完全な秘匿 wrapper に接続し、実際の業務入力からの経路と独立した承認・保管を確認する。

  • 受付・担保差入・限度・支払の原子化

    付与と受付は別々の呼び出しであり、差し入れた担保をロックする状態がない。要件としては書いてあるが、実装していない。

  • 状態の世代番号の永続化

    暗号化したキュー、レート制限のカウンタ、nullifier 台帳を認証付きの記憶域に置き、再起動をまたいで保つ。ロールバックでリプレイが再び通ることを防ぐ。市場を 2 プロセスで動かしたときに、許容量がすべて二重になることも防ぐ。

  • 本番運用に必要な周辺

    mTLS、テナント別の認可、OpenAPI、レート制限、監査ログ、外部の KMS/HSM、鍵のローテーション、バックアップと復旧。現状はデモ用の API しかない。

  • ノード間のオフライン段階

    オンライン段階の通信は、trusted dealer（前処理を配る信頼された第三者）ありで全バイト数の 16% と計測済み。7 ノードの間で実際に前処理を行うプロトコルは実装していない。

  • 差分プライバシー開示のバイアス補正

    DP 開示は、非線形な統計量に生じる上方バイアスのため、開示なしより悪い結果になった（計測済み）。純粋な DP を主張する前に、MPC 内のサンプラーを厳密で上限のない構成にする必要がある。

  • 遅い委員会向けの参照価格の補正

    勝者は参照価格に依存しない。価格は参照価格のアフィン関数（一次式）である。それでも現在の実装は、計算にかかった時間だけ古い価格を返す。

業務システム、用途調査が勧める順に

  • 1. ファンドの申込と解約

    発行者、管理者、投資家、KYC でそれぞれ別の鍵。資格、上限、予約、発行可能な口数を一つの zkPI に束縛する。資金の note と口数の note を一緒に更新する。超過申込、期限切れ、リプレイ、片脚だけのテスト。

  • 2. 担保と証拠金

    資格、ヘアカット、集中度を承認済みの回路として扱う。秘密のままのポートフォリオに対してカバー率を証明する。差替えと返還。主体ごとの上限の下での同時呼び出しの順序付け。研究テーマとしては最も強い。

  • 3. 二通貨 PvP

    一つの指図に 2 つの発行者と 2 つの予約を載せる。障害、期限切れ、再起動、再送のテスト。ISO 20022 は外部アダプタで扱う。

  • 4. 外部台帳との接続

    ファンド、担保、銀行の模擬台帳を独立したプロセスとして立てる。署名付きの予約と受領証。どの障害が原子性を壊すかの明示的な一覧。

コードの外の事情に阻まれているもの

  • WAN 上の独立した運営者

    7 つの MPC 運営者、5 以上の検証者、それぞれ別の管理者、鍵保管、障害領域。残っている最大の未知であり、リスク登録簿が最も難しいとしている項目である。

  • 実用 note の秘密計算関係と安全性

    限定した 4 口座の協調証明と正規台帳への反映には研究実証がある。未解決なのは、実用 note の秘密の所属、支出権限、出力暗号化、数量・資産保存と市場の全ライフサイクルを一つの正しい関係へ結び付けること、および構成全体の外部安全性検証である。

  • 法的 finality と登録簿への接続

    振替口座簿、CSD、中央銀行または指定された資金脚、監督当局の開示手続き。EU と英国では非株式の RFQ が自然な置き場所であり、スイスでは台帳の記録がそのまま権利になり得る。

  • 独立した監査

    第三者による、暗号、Rust の状態機械、ホスト VM、統合の監査。内部レビュー 2 回はこれに当たらない。

未解決の研究課題

  1. ランダムオラクルだけを前提に何度でも開ける、公開検証可能で線形準同型な F_p 上の commitment。
  2. 群の位数も収まる体での、slack（比較に許す余裕）のない比較。7 者 Shamir 向け。
  3. honest majority で公開の説明責任を持たせる費用。
  4. OCLOB の形式的な安全性定義と証明。通信の漏れと選択的な停止を含む。
  5. Prime Match の 2 ラウンドの malicious 比較を、7 者 Shamir に移せるか。