暫定結果とchallenge
QOMMとOCLOBで共有する担保付きclaim。challenge時に元の証拠を検証し、正本での確定後にnative決済へ進む。
一つの決済台帳で、二つの検証方式を使う
共同証明は元の実行証明またはattestationを決済前に取得します。暫定方式は担保と実行文脈に結ばれたclaimを先に登録し、challengeを受けた場合に元の実行証拠を要求します。どちらでも、選んだ決済経路の金銭関係の証明と正本検証は必要です。
共有状態機械はzkpi-optimistic、正本を読むドライバはzkpi-defmi-sdk、policy・担保・確定状態はDeFMI VMが担います。QOMMとOCLOBはアプリ固有の検証器を提供します。ローカルtimerや画面表示だけで送金権限は生まれません。
proposalが拘束する対象
ガバナンス承認されたpolicyで、network、application、検証器ID、提案者、担保資産、双方の担保額、時間窓を固定します。登録されたexecutionはjob、入力root、更新前状態、有効期限を持ちます。ノードはその実行に結ばれた署名済みadmissionを検証し、結果のclaimへ署名してproposalを永続化します。
決済側の参照は確定claimと今回の実行を結びます。policy、検証器、入力snapshot、結果digestを差し替えても有効なままではいけません。以下は項目の対応を示す式で、wire形式の定義ではありません。
{\rm context}=({\rm network},{\rm application},{\rm verifier},{\rm job},R_{\rm input},R_{\rm before})正本の状態遷移と期限の境界
| 状態／操作 | 正本の条件 | 結果 |
|---|---|---|
| 提案 | 登録済み実行、有効な署名、提案者の十分な担保 | Pending。提案者担保を拘束 |
| Challenge | Pendingかつブロック時刻 < challenge期限。申立者担保が十分 | Challenged。応答期限を設定 |
| 応答 | Challengedかつ時刻 < 応答期限。元の検証器が同じ実行の証拠を受理 | Proven。元のchallenge期限を待つ |
| 正しいが提案と矛盾する証拠で応答 | 応答期限内に元の検証器が別の結果を検証 | Rejected。提案者担保を申立者へ移転 |
| Pending／Provenをadvance | 時刻 ≥ challenge期限 | Finalized。決済の権限検証へ進める |
| 未応答challengeをadvance | 時刻 ≥ 応答期限 | Rejected。決済不可、提案者担保に罰則 |
不正な証拠bytesは拒否しますが、その提出だけで直ちに担保を没収しません。応答期限内なら有効な証拠を提出できます。期限切れ後のadvance取引で棄却を記録します。画面の残り秒数は目安で、正本ブロック時刻が権威です。
担保も正本状態の一部
native VMは指定された担保資産をescrowへ移し、利用可能・拘束中・罰則の残高を別々に管理します。policyへ担保の数値を書くことだけでは資金供給になりません。challengeなしの確定で提案者担保を解放し、有効応答では申立側、未応答では提案側へpolicyの罰則を適用します。
ブラウザデモでは明示的に公開開発用の鍵と合成担保を使います。確認環境の待ち時間はQOMMが20秒・応答30秒、OCLOBが30秒・応答45秒です。policyの設定値であり、プロトコル共通の定数でも、経済安全性を評価済みの値でもありません。
保証の内容は元の検証器で決まる
- QOMM
- quote用のchallenge adapterは、コミットされた実行へ結ばれた元の数学的quote証拠を検証します。決済に残る金銭関係の証明とは別です。
- OCLOB
- transition用adapterは既存の委員会attestationを検証します。価格優先・時間優先の全規則を新たにZK証明したものではありません。数量・価格・積・残額の共同証明は別に残ります。
- Challengeなし
- 登録policy、担保を持つ提案者、有効なchallenge機会に依存します。省略した元の証拠を数学的に検証したことにはなりません。
ブラウザから実際の経路をたどる
- 実行中でない時に共同証明／暫定方式を選びます。選択はサーバーに保存します。
- QOMMは注文者の席へ参加し、OCLOBは法人の視点で注文を出します。
- 暫定方式では参加者向け画面に暫定価格／約定を表示します。challenge期間中は資金と秘密板を確定しません。
- 必要なら同じ画面からchallengeを送ります。ボタンは正本のchallenge取引を送信し、画面状態だけを模擬しません。
- claim確定後のnative決済receiptまで待ち、残高と公開板の変化を確認します。
OCLOB HTTPサーバーのin-process決済へのfallbackは削除しました。両方式とも5台のnative Avalanche検証ノードを使います。この変更は、別に存在する参加者側native-note APIへの入力経路移行ではありません。
デモの視点は自由に選べる投影で、認証によるアクセス制御ではありません。OCLOBは暗号化・秘密分散前にcoordinatorが平文を受け取り、7プロセスは一つのホスト上で動きます。開発UIへ実注文・実資産・非公開の本人確認情報を入れる用途ではありません。
確認した範囲と復旧上の制約
この観測は統合作業ツリーで実施しており、文書の公開は後のソースcommitの配備を意味しません。2026-09-12に、QOMMの画面から指値159.07・数量1を送り、157.18の約定とchallenge後の決済を確認しました。OCLOBでは100円×100口の売りに対し、指値101円で共同証明20口、challengeなし暫定40口、challengeあり暫定20口を送り、すべて100円で成立しました。買い手の結果は資金99,992,000・在庫10,080口です。限定したnative環境での合成データによる機能確認であり、処理性能・独立運営・本番安全性の受入れではありません。
OCLOBは暗号化outboxと正本receiptを残しますが、このHTTP coordinatorの秘密板はプロセス内です。状態ディレクトリの再使用は拒否し、不明なnative決済結果を盲目的に再送しません。新しいブラウザセッションには新しい隔離開発ネットワークを使います。別のnative node経路にある復旧実装とは区別します。
実装と確認記録の参照先
使用環境へ配備されたpolicyと検証器の版を確認してください。以下の共有実装が仕様の参照先で、ブラウザガイドに起動手順と確認記録を残します。