OCLOB: 注文を見ない連続指値板

連続で動き、バッチ処理をしない指値板。到着順が確定し照合が終わるまで、運営者は売買の向き、価格、数量、参加者を見ない。公開板に載るのは価格帯ごとの合計数量である。約定は事前承認済みの zkPI 指図として DeFMI で決済され、照合後の再署名はない。

出典: oclob/README.md, docs/ARCHITECTURE.md, docs/THREAT_MODEL.md, docs/STATUS.md, docs/RELATED_WORK.md

防ぐもの

通常の分散型 CLOB では、注文は照合される前に検証者、シーケンサ、mempool の監視者に見える。見た者は、その注文の前に有利な注文を差し込んだり、都合の悪い注文だけを遅らせたりできる。OCLOB が直すのは一点である。処理待ちの注文の内容を読み、その前に自分の注文を置くこと。次のものは防がない。公開板からの通常の予測、約定後の板の変化からの推測、通信タイミングの観察、MPC ノード 3 台以上の共謀、ネットワーク妨害による停止。

処理の順序

1. メイカーは板に注文を置く前に、在庫または資金の上限を予約する。テイカーは発注時に、予約と、自分の限度内での約定を事前承認する。
2. 注文は参加者の手元で秘密分散される。公開されるのは commitment（内容を隠したまま固定した値）だけである。
3. 7 ノードのうち 5 台が到着番号に署名する。
4. 7 ノードが MPC の中で価格・時間優先の照合を行う。到着番号は変えない。
5. 遷移証明が、約定と公開板の更新を結び付ける。
6. 閾値 zkPI を組み立て、資金と証券を DeFMI で同時に決済する。
7. DeFMI から正式な受領証が届いてはじめて、画面に「決済済み」と表示する。

flowchart LR
    CORP["参加者モジュール
署名、DeKYX、予約"]
    QUEUE["暗号化した永続キュー
停止中も順序を保つ"]
    ORDER["到着順委員会
7 のうち 5"]
    MPC["秘匿照合
MP-SPDZ、7 プロセス"]
    PROOF["遷移証明
到着 + 板 + 約定"]
    ZKPI["閾値 zkPI
約定の範囲だけ"]
    DEFMI["DeFMI
資金と証券を同時に"]
    BOOK["公開板
価格帯別の合計"]
    CORP --> QUEUE --> ORDER --> MPC --> PROOF --> ZKPI --> DEFMI
    MPC --> BOOK
    DEFMI -->|"正式な受領証"| CORP

意図して分けた四つの状態

• 参加者の秘密状態: 注文の全内容、署名鍵、DeKYX の資格証明、予約 commitment の開封値。
• MPC の秘密状態: 各ノードが持つシェア。対象は注文と、板に残っている注文。ノード 1 台だけでは値を読めない。
• 公開状態: 市場 id、到着番号、注文の commitment、価格帯別の合計、約定、検証の証拠、DeFMI のルート・ダイジェスト。
• 決済権限: 事前署名済みの注文と DeKYX の提示。固定長の暗号文として、決済側にだけ届ける。

分散経路では、参加者が検証可能な 3-of-7 の Pedersen 分散を作る。シェアはノードごとに一つで、そのノードの鍵で暗号化し、相互 TLS の上を固定長のメッセージで届ける。だからメッセージの大きさは注文の内容によって変わらない。各ノードは署名付きの保存受領証を返す。受領証の対象は、注文のダイジェストと、そのノードが永続化した状態の世代である。公開用の要約は注文ごとの使い捨て鍵で署名する。だからコーディネータには、注文も参加者の長期鍵も渡らない。

内容を見ずに到着順を決める

5 ノードが署名する言明に含まれるのは (market id, arrival number, order commitment, previous certificate digest, expiry) だけである。各ノードは署名する前に自分の票を永続化し、同じ窓の中では同じ番号に別の注文を署名しない。MPC への要求は、証明書のダイジェストだけでなく本体を運ぶ。各ノードは実行前に、固定された 7 つの公開鍵に対して、署名の数、対象、連鎖の連続性を再検証する。互いに矛盾する 5-of-7 の証明書が二つ存在することはない。5 台の組をどう二つ選んでも、正直なノードが少なくとも一つ共通に含まれるからである。これは、世界のどこでどのパケットが先だったかについての主張ではない。非同期ネットワークには到着の全順序がない。この設計は、観測した順序と、証明できる確定規則とを切り分けている。

照合と板

買いは高い方から、売りは安い方から、同じ価格帯の中では到着番号の順に照合する。MPC は 8 スロットの固定バッチを評価する。開くのは、各スロットが約定したか、約定の価格と数量、到着した注文の公開してよい残量だけである。参加者、DeKYX の nullifier、鍵、予約 commitment の開封値は開かない。一度に 8 スロットを超えて約定しうる注文は、黙って切り詰めるのではなく、受付の時点で拒否する。公開板は (side, price tick, total resting quantity) であり、注文の件数は公開しない。参加者が一人だけの価格帯では、合計の変化からその参加者の数量が漏れる。この漏れは、匿名性の主張とは別に計測している。

事前承認済みの決済

参加者は発注時に、次の条件をすべて満たす約定なら自動で決済してよい、と署名する。指値より不利でない。数量と予約の上限の内である。期限内である。指定した市場、銘柄、DeFMI の上である。公開された価格・時間優先の規則の下である。だから照合後の再署名はない。結果を見てから署名を拒んで、相手を探ることもできない。実装は二段階である。板に残る GTC のメイカー注文は、MPC が「約定なし、板に残す」と判定した時点で、秘密の上限に対する閾値 zkPI と、予約ルートの対を受け取る。そして Avalanche の finality の後にはじめて、照合対象の集合に加わる。到着したテイカーが約定すると、その予約、すべての約定、未使用分の解放が、一回の DeFMI の compare-and-swap として適用される。L1 が拒否した場合、秘密の板、法人単位の上限、残高、DeKYX の一回限りの状態はすべて元のままである。

資格と法人単位の上限

参加には DeKYX の匿名提示を使う。資格の名前空間は org.zkfmi.oclob.legal-entity-participant である。scope 別の nullifier により、一つの法人が同時に出す注文は、板全体で一つの予約上限を共有する。その上限の外部設定は DeCCP と DeFMI が持つ。

何を、どこで受入したか

統合受入は、管理者一人が管理する Linux ホスト 1 台で行う（開発用の Mac ではビルドしない）。確認した項目は次のとおりで、すべて同じ注文ダイジェストの上で確認した。参加者側での分割。7 つの MPC コンテナへの直接配送。メイカー予約。テイカー予約と、検証者 5 台の非 EVM DeFMI L1 上での複数約定の DvP。全検証者間でのルートの一致。再送された遷移の拒否。検証者 1 台の再起動後の復旧。React Flow のデモは 1440×1000 と 390×844 で操作し、横方向のはみ出しはゼロ、コンソールエラーもゼロだった。

artifact（計測の出力ファイル）: oclob_distributed_avalanche_acceptance.json, oclob_distributed_e2e.json, oclob_rough_e2e.json

先行研究との位置関係

「秘匿した注文を MPC で照合する DEX」は新しくない。Rialto、P2DEX、Renegade は明確な先行例である。TEE ベース（Tesseract）、commit してから開く方式、バッチ方式、分散した公開 CLOB の設計も存在する。OCLOB は暗号部品の新規性を主張しない。差になりうるのは、次のものを一つの状態機械に組み合わせたことである。バッチではなく連続の処理。可変数量、部分約定と複数約定、GTC、IOC、取消、期限を秘密状態のまま扱うこと。内容を開く前に 5-of-7 で到着順を確定し、それを時間優先に結び付けること。価格帯別の合計板を連続して公開すること。匿名の法人資格、法人全体での予約、閾値 zkPI、照合後の署名を要しない原子的 DvP。P2DEX の UC 安全性と、不正なサーバに対する補償は OCLOB より先を行っており、未解決の課題として挙げている。TEE は意図して信頼境界に入れていない。

技術スライドから実装へ

37項目の暗号技術カタログで用途・数式・証明者・制約を確認し、予約から決済・回収までで状態遷移をたどれます。暫定結果とchallengeは、両デモの検証方式とnative決済の境界を説明します。