配置の選び方
計測値のそれぞれから、どの運用条件で何を選ぶべきかを読み取る。推定値と計測値は区別して示す。最初の判断は他のどの選択よりも重い。そしてそれは暗号の判断ではない。
出典: qomm/DEPLOYMENT.md · artifact（計測結果のファイル）: placement.json, sites.json, staleness.json, binding_chain.json, prep_split.json, probe_budget.json, distributed_dp.json
最初の判断: ノードをどこに置くか
片道 15 ms の配置では、見積 1 件に 3.68 s かかる。そのうち 2.13 s は純粋な往復時間で、回路をどう変えても減らない。7 ノードを一つの都市圏に置く効果は、暗号面の改良をどれだけ積み上げるよりも 6 倍大きい。その代わり、一つの都市圏に置くと、7 ノードがまとめて結託する危険が高まる。同じ法域、同じ商圏にある 7 ノードでは、T=2 の仮定を支えるのは組織の独立性だけになる。これは統治の問題であり、遅延と明示的に引き換えにするものである。
独立性は委員会の内側では買えない。 分かりやすい妥協案がある。6 ノードを一つの都市圏に置き、7 台目だけを別の法秩序の下に置く案である。しかしこの案には、7 台すべてを遠隔に置く費用の 86% がかかる。ラウンド数は 70 で一定であり、壁時計時間（実際に経過する時間）は最も遅い回線を待つからである。線形モデルは 15 ms では 1.4% の精度で検証できたが、120 ms の場合は 28% 低く予測した。だからそれ以上の外挿もすべきでない。
26 秒の重みは長さでは決まらない
遅い委員会が問題になるかどうかを決めるのは、遅延の長さではない。その間に価格が動いたかどうかである。UniswapX の約定には、あるブロックの時点で執行可能だったレートが付いている。だから、時間差の間の価格の動き（drift）を、同じ市場が一つのブロックの中で見せる散らばりと比べられる。
| 時間差 | 価格の動き | ブロック内の散らばりとの比 |
|---|---|---|
| 1 ブロック内 | 4.8 〜 7.5 bp | — |
| 2 ブロック、約 26 s: 地域をまたぐ見積 1 件分 | 3.6 〜 8.6 bp | 1.01×（中央値） |
| 8 ブロック、約 96 s | 7.4 〜 9.4 bp | 1.34 〜 1.75× |
| 25 ブロック、約 300 s | 12.2 〜 19.2 bp | 1.63 〜 4.00× |
26 秒間の価格の動きは、市場が一つのブロックの中ですでに持っている価格の不確かさと同じ大きさである。しかもこれは、入手できる中で最も厳しいレール（決済経路）での値である。したがって基準は遅延ではない。その銘柄自身の価格の不確かさに対して、価格の動きがどれだけかである。スプレッドがベーシスポイント単位の銘柄なら、地域をまたぐ委員会は許容できる。スプレッドがその何分の一かの銘柄なら、許容できない。よって区分は銘柄ごとになる。漏れが最も痛い RFQ（広いスプレッド、薄い板、大きなサイズ）に地理的に散らした委員会を使う場面は、26 s が最も安く済む場面でもある。request-for-stream は往復が critical path（全体の時間を決める経路）から外れるので、RFQ より遅延に耐える。地域をまたぐ決済はもともとラウンド数に縛られていない。自地域の外へ見積を出すメイカーにも、両地域をまたぐ委員会は要らない。値付け規則は一度だけ、オフラインで境を越えればよいからである。
価格の動きの代価は、そもそも払わなくてもよい。見積は参照価格のアフィン関数（一次式）であり、勝者は参照価格に依存しない。だから遅い委員会は、開始時点の参照価格で走らせ、開示された価格を後から補正できる。この性質はテストで確かめてあるが、実装はまだ使っていない。
三つの配置プロファイル
都市圏内、監査なし、遅延優先
- 同一都市圏、片道 1 ms: 見積 1 件あたり 0.617 s
- 31 ビット、二分トーナメント、バッチ数 Q は到着率に合わせる
- quote proof なし: +550 ms を避ける
- malicious Shamir: semi-honest の 1.12 〜 1.24× で、安い
- 群の位数上の Shamir 入力と、参加者ごとの入力検査
1 秒未満の見積と、約定しない依頼の秘匿（AUC 0.500）を与える。計算が正しかったことの証明は与えない。受領証はノードを結果に束縛するが、結果が正しいことは示さない。
都市圏内、監査あり、ほぼ即時
- M ≤ 16 での quote proof: 証明 317 ms、検証 400 ms
- 三つの時間の合計: 824 + 551 + 655 ms = 2.03 s
- RFS（request-for-stream）の更新間隔は 3 s 以上。1 秒は満たせない
- 開示間隔 60 s
- 束縛は必須。何も検査していない入力についての quote proof は、間違った命題の証明である
各スロットで検証可能な計算を与える。1 秒未満で決済できる速さは与えない。
広域、バッチ処理
- 地理的に分散する。統治上の独立性を最優先するときに選ぶ
- バッチ Q は 16 〜 32: Q=32 で見積 1 件あたり 284 ms
- 利用者一人の待ち時間は Q=32 で 9.09 s
- 束縛はプロファイル B と同じ。その通信量を最も負担しにくいのがこのプロファイルであり、必要性は同じだけある
即時性より秘匿と分散を重んじる市場に向く。片道 15 ms では T(Q) ≈ 3.4 + 0.18Q 秒である。目標の待ち時間 W に対しては、Q ≤ (W − 3.4)/0.18 を満たす最大の Q を取る。
既定で off のスイッチ
quote proof は、開示された価格が、ノードの使った入力の正しい関数であることを証明する。その入力が、配られ commit されたシェアそのものかどうかは別の話である。そこを閉じるのは、別々の相手を捕まえる二つの仕組みである。どちらもコマンドラインのフラグで、既定は off である。--shamir-inputs は回路を commitment 群の体の上で走らせ、commit したものと違うシェアを配る dealer（シェアを配る側）を捕まえる。--input-check はノードごとに一つの線形結合を開示し、シェア検査を通ったあとで別の値を入れたノードを捕まえる。両方合わせて 2 ラウンドと 2.03× の通信量がかかる。既定が off なのは、研究用ハーネスの都合である。すべての arm（比較する構成）を選べる必要があり、通信量を倍にする既定では arm どうしを比べられなくなる。配備にはそのような理由はない。これらなしで監査ありのプロファイルを走らせる配備は、何も検査していない入力についての証明を公表することになる。見直しで、配置ガイドが当初どちらにも触れていなかったことが分かった。計測値は束縛のページにある。
スロット間の前処理
一回の実行で消費する相関付き乱数は、依頼の内容には依存しない。回路の形だけに依存し、回路の形は固定で、コンパイルは一度だけである。前処理をディスクに置いておくと、オンライン段階は参加者 0 のバイト数の 16%、ラウンド数の 71% になる。この数字は遅延ではなく帯域として読む。ラウンド数は回路の深さであり、往復 17.4 ms で 44 ラウンドなら依然 0.77 s かかる。この計測は trusted dealer（前処理値を配る信頼できる第三者）を使ったが、それはどの配備も動かせない。だから決まるのは、オフライン段階を作る価値があるか（バイト数が 6 分の 1 になるので、ある）だけであり、その段階に何がかかるかではない。
各構成要素の選び方
| 構成要素 | 選択 | 計測上の根拠 |
|---|---|---|
| 匿名資格、N ≲ 8 | OR 合成 | N=8 で証明 1.21 ms。上限を決めるのはメイカーの端末で証明する時間 |
| 匿名資格、N ≳ 16 | Groth–Kohlweiss の one-of-many（多数の中の一つであることの証明） | N=128 で検証が 2.35× 速く、証明は 5.1× 小さい |
| quote proof 内の範囲証明 | Bulletproofs | Rust で計測: 証明一式で 10.5×、検証で 6.3×。幅は 2 の冪に固定される |
| 差分プライバシーによる開示 | 閾値開示（arm B）を既定のまま | DP 開示は開示なしより悪いと計測された（約定率 −0.039、メイカー P&L −100.7）。原因は非線形な統計量の上方バイアスで、再計測の前に補正が要る |
| 脅威モデル | malicious Shamir | 見積回路では semi-honest に対し壁時計時間 1.12 〜 1.24×、通信量 2.9 〜 3.2×。比較演算からなる開示回路では 1.9× と 6.0× |
| 複数資産 | 全市場を一つのジョブで処理 | 資産数 1 から 32 まで 70 ラウンドで一定。通信量は資産 1 つあたり +0.04 MB |
| 決済指図 | zkPI。対象に複数の資産が含まれるときは常に使う | 発行 11.8 ms、検証 12.6 ms、nullifier（二重使用を防ぐ使用済み印）32 B。別の市場にもそのまま持ち込める |
| レール幅 | 最大数量と通貨の最小単位から決める。両レールで同じ幅にはしない | 暗号を一行も変えずに効く唯一のレバー。ただし Bulletproofs では 2 の冪に丸められる |
| 銘柄の秘匿 | 銘柄それ自体が情報になる場合は asset tag（銘柄を隠した印） | 決済 1 件あたり +32 B。所属証明は発行時のみ |
| ネッティング | 失敗が許されなければグロス、流動性を優先するならネット。配分を第三者が検証できなくてもよいなら、1 サイクルに attestation（委員会の証明書）1 つ | 取引ごとに検証すると N=256 で 12.6 s。サイクルごとなら 0.2 s |
| 相手先の秘匿 | 関係それ自体が情報になる場合は note（受取人を隠した残高の単位）。ring（おとりを含めた候補集合）は 64 | ring は支払側の端末が決める。wire（通信路上のサイズ）は ring が倍になるごとに 224 B 増える |
| 中継 | 2 ホップ以上 | ホップあたり約 4.4 ms。1 ホップでは中継者に利用者の IP が見える |
配備前に人が決めること
- ノード運営者の独立性。 T=2 は結託する 2 ノードまで耐える。一つの都市圏に置けば地理的な独立性は手放す。だから運営者、法域、親会社の独立性がその分を担わなければならない。
- bond（担保として預ける金額）の大きさ。 スラッシング（不正時の没収）の規則は相対的な重みしか持たない。絶対額は、不正で得られる利益の見積もりから導く。
- 目標とする RFS の更新間隔。 監査ありなら 3 s 以上。1 秒にするなら、軽い証明にするか監査をなくす。
- 主体ごとの上限と、その計数器を置く場所。 メイカーの在庫を、そのメイカー自身の両建て見積から読み取る攻撃がある。これは暗号が手を出せない唯一の攻撃である。確定価格を返すことこそが、このプロトコルの存在理由だからである。24 個の seed で計測すると、相関は約 0.53 で、探りの予算を増やしても大きくならない。大きくなるのは確信の方である。10 回の探りでは seed の 23% で確信に至り、24 回で過半数、96 回でほぼ全部になる。したがって上限が決めるのは、主体が像を得られるかどうかではない。どれだけの頻度で像を更新できるかである。出荷時の既定は 1 epoch あたり 60 依頼。メモリ上のレート制限器は再起動で初期化され、インスタンス間で合算されない。だから二つのプロセスで動かす市場は、すべての主体に二倍の枠を与えてしまう。永続化と共有は、まだ行っていない配備側の作業である。
- 決済先が何を受け入れるか。 zkPI の指図の範囲、すなわち数量と価格の下限・上限と期限の幅は、決済先の市場が公表するものである。狭くすれば安全だが、正当な取引も拒む。
未検証だが、判断に関わること
| 項目 | 状態 | 判断への影響 |
|---|---|---|
| 実際の 7 拠点での配備 | 2 拠点まで計測済み（実 RTT 17.4 ms、正味 1.66 s） | 7 拠点を運用し、障害から復旧させる方法は未知。残る最大の未知 |
| 薄い市場での開示停止率 | 未検証 | 薄い市場で arm B が常に開示を差し控えるなら、開示方式の選択が変わる |
| 他のデータでの再現 | 未検証 | ステージ 3 の結論は生成データの上に立っている |
| MPC 参加者プロセスの常駐 | デモ用 runner では実装済み（2026-09-08、ハイブリッド TLS）。ネイティブ受入の 7 プロセス構成は、いまもラウンドごとに起動している | Q=32 で見積 1 件あたり 5.3 ms。Q=1 のときだけ問題になる |
規模の目安（企業向け PoC ガイドから）
DeFMI の日本語 PoC ガイドは、出発点となる構成を示している。性能保証ではないと明記した上でのものである。単一ホストでの機能確認は 8 vCPU、16 GiB、100 GiB NVMe。検証者 5 台の PoC では、各検証者が 8 vCPU、32 GiB、500 GiB で、データベースとログは検証者ごとに持つ。検証者の RPC を外に出さない API ゲートウェイの背後に置く。正本台帳ではないインデクサ、分離した署名器 / HSM ゲートウェイ、監視、そして別ホスト上の負荷生成器を伴う。本番に近い配置は、専用または予約済みの CPU で、少なくとも三つの障害ドメインにまたがる。メモリのオーバーコミットとバースト型 CPU は、通常運用では何も見せないが、負荷時に合意の遅延を起こすからである。ガイドは、混同しやすい閾値も区別している。検証者の合意、MPC の k-of-n、FROST の署名定足数、DeCCP の承認重み、ドメイン間委員会の重みは、五つの別々の数字である。一つの組織がそれらを全部握っているなら、プロセスの数は独立性について何も語らない。