ZK検証可能なマッチングは、高速でプライベートな注文帳を運用しつつ、マッチングエンジンがルールに従っていることを暗号学的に保証する方法です。 解決する問題はシンプルです:CLOBは注文を素早くマッチングするためにオペレーター(または少数のオペレーター)が必要ですが、そのオペレーターは不正行為(順序付け直し、スキップ、選択的入力)も可能です。 ZKは信頼モデルを変えます。オペレーターは高速でいられますが、正しく計算されたことを証明しない限り更新を最終決定できません。 仕組み(概念的には) † 注文はオフチェーンで収集・マッチングされるため(低遅延実行が可能です)。 † システムは完全な注文フローを公開する代わりに、次の情報を公開します: - バッチ/状態遷移へのコミットメント(多くの場合、状態ルート) - マッチング+リスクチェック+バランスの更新がプロトコルルールに従って行われたことを示すzk証明、 - オペレーターがいなくなった場合でもユーザーが退出できる十分なデータ利用可能性。 「十分なデータ可用性」が@hibachi_xyzの設計選択の興味深い点です。 Hibachiは高性能CLOBを実行し、暗号化された状態/取引データを@Celestiaに投稿しています(そのため戦略やポジションは公開されません)一方で、更新が検証可能にできるよう証明も公開しています。SP1(SuccinctのzkVM)を使ってCLOBを証明しています。 しかし、「一致が正しかった」というのは証明の意味とは何でしょうか? zk証明は、通常交換演算子が従うべき不変量を強制できます。例えば: † 注文は価格が交差した時のみマッチングされ(不可能なフィルはなし)。 † フィルシーケンスは会場の優先順位ルール(例:価格・時間優先権、または会場が指定するもの)を尊重していました。 † 残高やマージンは正しく更新されていました(隠れた残高編集はありません)。 ...