全体構成

従来の市場基盤は、三つの仕事を一体にして行っている。取引を決める、その決済を指図する、決済する、の三つである。zkFMI はこれを切り離す。それぞれの仕事は別の構成要素が担い、各構成要素はその仕事に必要な秘密しか持たない。構成要素の間を渡るのは commitment（値を隠したまま、後から変えられない形で固定したもの）、証明、署名だけである。平文は渡らない。

システムの形

このサイトでは次の三つの語を使い分ける。指図の発行元とは、資産の移転を決めて zkPI（証明付き決済指図）を発行するもの全般をいう。市場は発行元の一種で、多数の当事者の注文や見積を突き合わせて移転を決める（QOMM、OCLOB）。業務システムも発行元の一種で、自分の業務規則によって移転を決める（ファンド管理者、担保エンジン、銀行の審査、Aethel）。決済層から見ると、この三者は区別できない。区別できないことが、この設計の狙いである。

flowchart LR
    subgraph up["指図の発行元: 決める"]
        Q["QOMM
依頼を見ない RFQ"]
        O["OCLOB
注文を見ない板"]
        A["Aethel
債権"]
        X["任意の業務システム
ファンド、担保、銀行"]
    end
    subgraph gate["資格"]
        K["DeKYX
匿名の資格証明"]
    end
    subgraph inst["指図する"]
        Z["zkPI
commitment 化した指図
+ 定足数署名
+ 範囲証明"]
    end
    subgraph clear["清算する（任意）"]
        C["DeCCP
ネッティング、証拠金、ウォーターフォール"]
    end
    subgraph settle["決済する"]
        D["DeFMI
note、asset tag、
DvP / PvP、照合"]
        L["Avalanche L1
検証者 5、Rust VM"]
        D --- L
    end
    K -.->|"検証済みの資格"| Q
    K -.->|"検証済みの資格"| O
    K -.->|"検証済みの資格"| C
    Q --> Z
    O --> Z
    A --> Z
    X --> Z
    Z --> C --> D
    Z --> D
    D -->|"受領証、状態ルート"| up
    classDef secret stroke:#f2b880,stroke-width:2px
    classDef mech stroke:#9bb0ff,stroke-width:2px
    classDef ok stroke:#5ee0c1,stroke-width:2px
    class Q,O,A,X secret
    class Z,K,C mech
    class D,L ok

この形から三つの性質が出てくる。他のページを読むときも、この三つを頭に置いておくとよい。

• 決済層は取引の中身を判断しない。DeFMI が確かめるのは算術だけである。金額の総和が保たれているか、負の値がないか、数量 × 価格 = 金額という積の関係が成り立つか、全部の脚が同時に確定するか、同じ指図が二度使われていないか。価格が妥当か、銘柄が正しいかは指図の発行元が判断する。その判断は定足数署名（一定数以上のノードが揃って作る署名）に載って運ばれる。DeFMI に同じ判断をやり直させるには平文を渡す必要がある。この構成は、まさにそれを避けるためにある。
• 外へ出るのは指図だけである。依頼、値付け規則、負けた見積は、指図の発行元の外に出ない。市場が公開するのは、commitment にした指図、nullifier（同じ指図の二度使いを防ぐ使用済み印）、期限、署名である。
• 指図の発行元はどれも入れ替えられる。最初に作ったのは QOMM だが、ファンド管理者、担保エンジン、銀行の制裁リスト照会も同じ型の指図を発行できる。業務システムのページでは、それらを実現しやすい順に並べている。

一件の決済を端から端まで

ここでは二つの発行元について流れを追う。一つ目は RFQ 市場（見積依頼の市場）である。これまでに作った中で最も完全な経路で、すべての証明を通るので選んだ。二つ目はファンド管理者である。MPC もオークションも使わないが、同じ型の指図で同じ決済層に到達する。業務システムのページは、これを最初の製品に位置づけている。OCLOB は、一つ目の経路の値付けの段を注文の照合に置き換えたものである。指図より後の段はすべて共通である。

RFQ 市場を通る経路

sequenceDiagram
    autonumber
    participant T as テイカー
    participant N as MPC ノード 7 台
    participant M as メイカー（値付け規則は事前に配布済み）
    participant Q as 3-of-7 の定足数
    participant V as DeFMI 検証者（5）
    T->>N: 依頼（銘柄、数量、売買方向）を加法シェアに分けて一定間隔で送る
    M-->>N: commitment 化した値付け規則を Shamir シェアとして配布
    N->>N: 全メイカーで値付けし、資格のない者を除き、二分トーナメントで比べる
    N->>N: 鍵を一つだけ開く: 勝者と commitment 化した価格
    N->>N: quote proof（見積の証明）: 勝者の鍵が commitment 化した鍵の中で最小であること
    N->>Q: 閾値範囲証明 2 本（金額、価格）を組み立てる
    Q->>Q: 指図に FROST 署名（nonce、期限、ダイジェスト）
    Q->>V: zkPI + 完全な quote proof + DvP パッケージ
    V->>V: 承認、指図、証明、価格制限、資産の紐付け、各ルート、nullifier を検証
    V->>V: 両脚を同時に適用する。片方だけは適用しない
    V-->>T: ブロック高、受領証、適用前後の状態ルート

ファンド管理者を通る経路

sequenceDiagram
    autonumber
    participant I as 投資家
    participant K as KYC 提供者（DeKYX）
    participant F as ファンド管理者
    participant Q as 発行定足数
    participant V as DeFMI 検証者
    I->>K: このファンドへの資格を証明（scope、上限、期限）
    K-->>F: 検証済みの資格。渡すのは subject line（scope 内の仮名）だけ
    I->>F: 申込依頼。現金は commitment 化した note（台帳上の残高の単位）として予約
    F->>F: 上限、残り口数、基準価額（NAV）の時点を確認
    F->>Q: 判断を型付きの指図にする: 現金脚、口数脚、期限、nonce
    Q->>V: 範囲証明と定足数署名を付けた zkPI
    V->>V: 検証してから、口数の発行と現金の移動を同時に行う。片方だけは行わない
    V-->>I: 受領証と状態ルート

決済層のどの部分も、指図がオークションから来たのか申込書から来たのかを知らない。以下の共通 crate の分け方も、この分離を保つ。

誰がどの秘密を持つか

リポジトリと crate

リポジトリは 8 つあり、各 crate の所有者は一つである。2026-09-08 から、共通の証明と委員会サービスを QOMM 専用のモジュールから分離した。表には実際のパッケージ名を示す。依存関係は zkfmi-crypto ← zkpi ← defmi ← qomm の順で、循環しない。OCLOB と Aethel も共通部分を使うが、QOMM には依存しない。リポジトリ間の依存先は変更不能な Git の rev（コミット）で固定する。

zkpi-proofs には決済にも使う閾値証明と quote proof を残し、zkpi-committee には証明サービス、承認、受取人向けの暗号化、状態を永続化する実行処理を残す。規則・方針・状態・流動性の監査と、市場の受付・配置用アダプタは QOMM が持つ。zkPI に残る qomm- という接頭辞は歴史的な名前である。defmi-avalanche-vm パッケージが生成するバイナリは、起動スクリプトに合わせて qomm-avalanche-vm のままである。

暗号プリミティブは書き直さず使う

すべて ristretto255 という曲線の上に作る。曲線の演算、範囲証明、閾値署名は監査済みの crate から借りる。このプロジェクトが自分で書いたのは、その上に載せたシグマ・プロトコル（知識の証明の基本形）のガジェット（部品）である。

flowchart TB
    subgraph ext["監査済み crate"]
        DALEK["curve25519-dalek
ristretto255"]
        BP["bulletproofs
範囲証明"]
        FROST["frost-ristretto255
閾値署名"]
    end
    subgraph zk["ゼロ知識のガジェット"]
        PED["pedersen
commitment、asset tag"]
        SIG["sigma
開封、生成元をまたぐ等価、積"]
        RNG["range"]
        OOM["oneofmany
Groth-Kohlweiss"]
        ORD["or_dleq"]
        ADP["adaptor
事前署名、適応、抽出"]
        SHA["shamir
Reed-Solomon 復号器"]
    end
    subgraph pi["指図の crate"]
        ISS["issuer
KYB クレデンシャル"]
        INS["instruction
commitment 化、束縛、nullifier 導出"]
        QUO["quorum"]
        HAN["handles
一つの seed から市場ごとに無関係な点"]
    end
    DALEK --> PED
    DALEK --> HAN
    BP --> RNG
    FROST --> QUO
    PED --> SIG
    PED --> OOM
    PED --> ORD
    SIG --> ADP
    SIG --> INS
    RNG --> INS
    OOM --> ISS
    ORD --> ISS
    INS --> QUO
    HAN --> INS

MPC が計算に使う体（数の集合）は、わざと commitment の群の位数に合わせている。MPC が commitment 群の位数と同じ素数を法として動くので、シェアに対する commitment は線形の式になり、監査人はその式を自分で再計算して確かめられる。この一致のおかげで、監査できるようにする代価は通信量が 2.00× になることだけで済む。同じ一致が、このスタックを格子ではなく離散対数の仮定の上に留めている理由でもある。この引き換えの両面がなぜ同時に成り立つかは、先行研究のページで説明する。

実行環境

実際に配置する先は、EVM を使わない専用の Avalanche L1 である。AvalancheGo が外側でコンセンサスを担い、RPCChainVM プロトコル 45 を通して Rust 製の VM を起動する。VM は、資産の登録、口座の開設、事前承認済みの予約、複数の脚を同時に確定する決済を、VM 自身の状態遷移として持つ。受入の経路には Solidity も EVM バイトコードもプリコンパイルも含まれない。

EVM と Solana を採らなかった理由は、推測ではなく計測の記録として残している。EVM バイトコードで ed25519 のスカラー乗算を 1 回行うと 302,401 gas かかった。Solana のランタイムには曲線演算の syscall はあるが、スカラー体の演算の syscall がない。そのため Groth–Kohlweiss の検証器が行うスカラー体上の多項式評価が、crowd（匿名集合の大きさ）64 で計算量の上限を超える。数値の表は zkPI のページにある。