他のシステムとの比較
このスタックと顧客の課題が重なる製品・基盤 18 件を、2026-09-05 に読み比べた。材料は各社自身の仕様書、発表、監督当局への提出資料である。結果は採点表ではない。次の三つの一覧である。差を述べられる軸、他者が先を行っている軸、そしてその結果としてこの計画が言ってよい文と言ってはいけない文。
出典: zkfmi-crypto/docs/research/COMPETITORS_EX_CANTON_2026-09-05.md · CANTON_NETWORK_2026-09-05.md · CANTON_FABLE_5_1_MAX_REVIEW_2026-09-05.md · COMPETITIVE_DECISIONS_2026-09-05.md (v1.2) · docs/strategy/ZKFMI_STRATEGY_2026-09-05.md · 調査に用いた一次資料は重複なしで 54 件、Canton の再検討では 38 件の URL のうち 37 件を再度開いた
段階ラベルの読み方
| ラベル | ここでの意味 |
|---|---|
| 商用事例の発表あり | 運営者または採用者が、目的の業務が動いたと述べている。独立した運用監査ではない。 |
| mainnet・alpha の発表あり | ネットワークの段階。規制市場での商用提供とは別物。 |
| 採用・実証・計画 | 発表が述べる段階のままにする。予定日が過ぎても稼働にはならない。 |
| 仕様を確認 | 運用モデルを文書で確認した。個別の配置の状況は未確認。 |
| 未確認 | 読んだ資料の中で確認できなかった。未実装や未対応とは異なる。 |
zkFMI 自身の基準も同じ日に読んだ。ホスト 1 台の上の研究ソフトウェアである。2 件の約定を 1 つの取引で決済したこと、連続取引を 2 ラウンド回したことについて、動作確認のみ(smoke)の証拠がある。ネイティブの note(一回限りの秘匿出力)の経路では、資産識別子と決済メタデータが公開である。耐量子のハイブリッド(古典方式と耐量子方式を組にしたもの)は、当日時点では単体実装だった。その後、ホスト 1 台での統合受入を通過した。耐量子化への移行を参照。Aethel はこのスタック上の業務システムであって競合ではないので、18 件に含めない。
18 件すべてを zkFMI と並べる
対象ごとにカードを 1 枚置く。Canton も含め、最後に zkFMI を置く。どのカードも同じ四つの問いで見る。この四つは、比較の中で決定的だと分かった問いである。緑は、文書化された標準経路でその性質が成り立つこと。琥珀色は、一部で成り立つか業務システム次第であること。灰色は、成り立たないか範囲外であること。各カードの下に、zkFMI をその対象から区別する一文を置く。これは差であって順位ではない。段階では、すべての対象が zkFMI より先にいる。
Canton (詳細)
mainnet 2024、商用のレポ基盤、米国債の実取引、日本での PoC 3 件- 運営者が注文を見ない
- 成り立たない。自社の validator(Canton で当事者をホストするノード)とアプリケーションが、平文の view(開示先ごとに分けた取引の部分)を読む
- 規則を外部者が検証できる
- 関係する当事者が Daml を再実行する。標準経路には持ち運べる証明はない
- 予約 → 原子的な決済
- 成り立つ。Token Standard の allocation、1 つの取引、平文で
- 決済が金額と価格を隠す
- 無関係な当事者と synchronizer(順序付けと確認を担う部品)に対してのみ
zkFMI との差 Canton は平文を誰が読むかを限定する。zkFMI は、7 ノード中 2 ノードまでの結託を許す前提(2-of-7)の下で、計算するどのノードにも完全な注文を渡さない。そして外部者が証明から規則を検証できるようにする。それ以外のすべてで Canton が先にいる。Canton は zkPI の検証器をホストしうる。
Renegade
mainnet、Arbitrum One- 運営者が注文を見ない
- 委任先の relayer(注文を預かって照合に参加する中継者)が読む。自分で relayer を動かせば避けられる
- 規則を外部者が検証できる
- 照合の正しさは証明される。注文集合と受付順は証明されない
- 予約 → 原子的な決済
- 約定はチェーン上で決済される。事前の予約は記述されていない
- 決済が金額と価格を隠す
- ウォレットの状態が秘匿される
zkFMI との差 Renegade は外部価格を用いた仲値でクロスする。zkFMI は、確定した受付順の上で価格・時間優先または RFQ を行う。Renegade の境界は relayer にあり、zkFMI は参加者側で注文を分割する。Renegade には資格と予約の脚がない。
Prime Match
J.P. Morgan で稼働、2023 年の論文- 運営者が注文を見ない
- 二つの顧客の間に、semi-honest(手順には従うが、見たものは覚える)な銀行のハブがある
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- 銀行の処理経路
- 決済が金額と価格を隠す
- 銀行が見る
zkFMI との差 銀行を中央に置いた二者間の在庫照合で、決済の脚はない。zkFMI は 7 ノードで、証明可能で、決済まで行う。Prime Match は先行例であり、「初」というあらゆる主張を退ける。
Penumbra
仕様を確認。封印入札のバッチは将来の機能- 運営者が注文を見ない
- 現行の仕様では swap の入力と数量が公開
- 規則を外部者が検証できる
- バッチ実行をチェーンが検証する
- 予約 → 原子的な決済
- 予約の概念がない
- 決済が金額と価格を隠す
- 移転と請求は隠す。swap は隠さない
zkFMI との差 Penumbra はブロック単位のバッチ・オークションで、swap の入力は公開である。zkFMI は連続する秘匿の板、または RFQ である。連結不能なウォレットと秘匿価格は別の行であり、Penumbra が持つのは前者で、後者ではない。
Dusk
mainnet の仕様、NPEX との協業- 運営者が注文を見ない
- モデル次第。暗号資産交換業者向けの経路は公開アカウントを使う
- 規則を外部者が検証できる
- チェーンによる検証
- 予約 → 原子的な決済
- DvP の設計が記述されている
- 決済が金額と価格を隠す
- 秘匿移転は任意
zkFMI との差 規制資産のための秘匿台帳で、秘匿された市場計算はない。zkFMI は市場と、最良執行の証明を加える。どちらも、清算コードの背後に免許を持つ清算機関はない。
Arcium
mainnet alpha- 運営者が注文を見ない
- MPC。honest(手順どおりに振る舞う)な参加者が 1 者いれば秘匿性を保つ
- 規則を外部者が検証できる
- 業務システムが定める
- 予約 → 原子的な決済
- 業務システムが定める
- 決済が金額と価格を隠す
- 業務システムが定める
zkFMI との差 汎用の MPC 基盤で、不正多数派を許し、逸脱があれば abort(計算を中断)する。zkFMI は、受付から決済までという一つの特定の業務を、honest majority(過半数が honest という前提)の MPC で行う。同じ業務は Arcium 上にも構築できる。それが評価すべき代替案である。
Zama
mainnet 2025-12、封印入札オークション 2026-01- 運営者が注文を見ない
- FHE(暗号化したまま計算する方式)。復号は閾値 KMS(鍵管理サービス)が行い、t < n/3
- 規則を外部者が検証できる
- 入力の知識証明とコプロセッサの署名であり、業務結果の証明ではない
- 予約 → 原子的な決済
- 業務システムが定める
- 決済が金額と価格を隠す
- 業務システムが定める
zkFMI との差 Zama は暗号化した状態のまま計算し、復号の権限は別に置く。zkFMI は MPC に証明を付ける。Zama は基盤で、zkFMI は業務である。一つの作業負荷の下でのコストと完了の挙動は、両側とも未計測。
Aztec
alpha V5。証明系の脆弱性を 2026-08 に開示- 運営者が注文を見ない
- クライアント側で証明を生成する。witness(証明の秘密入力)はクライアントを離れない
- 規則を外部者が検証できる
- クライアント自身の取引について
- 予約 → 原子的な決済
- 業務システムが定める
- 決済が金額と価格を隠す
- 秘匿状態
zkFMI との差 Aztec では、一者が自身の秘密について証明する。zkFMI では、複数の企業が互いの秘密の上で計算する。zkFMI の照合には後者が必要。どちらも監査を受けていない。
Hyperledger Fabric
仕様を確認、広く配置されている- 運営者が注文を見ない
- 認可された peer(組織ごとのノード)が秘匿データを読む
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- chaincode(Fabric のスマートコントラクト)
- 決済が金額と価格を隠す
- 他の組織からのみ隠す
zkFMI との差 Fabric では、どの組織がデータを見るかをアクセス制御が決める。zkFMI は、計算する組織自身が見てはならない場合のためのものである。その場合がなければ、Fabric の方が簡明な答えである。
R3 Corda
CSD Prague の決済に採用- 運営者が注文を見ない
- 参加者は見る。非検証型の notary(取引の一意性を確認する役)は、状態の参照を見る
- 規則を外部者が検証できる
- 参加者が検証する。外部への証明はない
- 予約 → 原子的な決済
- 契約状態と一意性
- 決済が金額と価格を隠す
- 参加者以外から
zkFMI との差 共有は契約の当事者間に限られる。秘匿計算も、市場規則の証明もない。採用実績は大きい。zkPI の連携候補。
Kinexys
商用、JPM Coin on Base 2026-04- 運営者が注文を見ない
- 銀行が見る
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- 銀行が運用する業務
- 決済が金額と価格を隠す
- 銀行が見る
zkFMI との差 顧客を持つ銀行自身の決済・トークン化サービス。zkFMI には資金脚(資金側の決済)がなく、このようなものが必要になる。
Fnality
ポンド建てシステムがイングランド銀行の制限の下で稼働- 運営者が注文を見ない
- システム運営者が見る
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- 支払いの取り決め
- 決済が金額と価格を隠す
- 運営者が見る
zkFMI との差 中央銀行に裏付けられたデジタル資金で、zkFMI に欠けている資金脚である。秘匿の価格形成は意図されていない。
Partior
決済が稼働- 運営者が注文を見ない
- 参加銀行が見る
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- PvP。DvP は概念実証
- 決済が金額と価格を隠す
- 銀行が見る
zkFMI との差 参加銀行の間では平文で行う、銀行ネットワークの PvP。zkFMI の PvP は、何も共有しない台帳の間で、adaptor signature(署名の完成と秘密の受け渡しを結び付けた署名)によりスカラー(秘密の数値)を渡す。資金脚の候補。
Ownera / FinP2P
API とオーケストレーション計画を公開- 運営者が注文を見ない
- 各機関のルータが見る
- 規則を外部者が検証できる
- 署名と受領証
- 予約 → 原子的な決済
- intent、hold(資産の保留)、台帳の能力に応じたオーケストレーション
- 決済が金額と価格を隠す
- ルータが見る
zkFMI との差 zkPI の位置に最も近い。台帳をまたぐ指図を、平文と署名で調整する。zkPI は、隠された命題の証明を指図に束縛する。「台帳をつなぐ」ことは差ではない。
Swift shared ledger
2026-07 に初期利用可能、パイロット準備中- 運営者が注文を見ない
- Swift と銀行が見る
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- 銀行間の確約。最終決済は既存システムで
- 決済が金額と価格を隠す
- 銀行が見る
zkFMI との差 Swift の規模での、トークン化預金の銀行間調整。銀行から隠すものはなく、計算するものもない。動向を追う。
Chainlink
機能を 2026-05 に記述- 運営者が注文を見ない
- TEE(ハードウェアの隔離実行環境)の内部では平文
- 規則を外部者が検証できる
- オラクル・ネットワークの署名
- 予約 → 原子的な決済
- クロスチェーンのメッセージ
- 決済が金額と価格を隠す
- 秘匿トークンが記述されている
zkFMI との差 Chainlink はハードウェアのエンクレーブと署名ネットワークに信頼を置く。zkFMI は MPC と証明に置く。「検証可能」という語が指すものが異なる。zkPI の運び手の候補。
Progmat
商用の ST 発行。Avalanche L1 への移行を発表。Canton 上での JGB レポ PoC- 運営者が注文を見ない
- 発行者、信託、販売会社が見る
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- 基盤上の ST の実務
- 決済が金額と価格を隠す
- 各役割が見る
zkFMI との差 日本のセキュリティトークンの発行と管理を、本番で行っている。zkFMI は、それらの役割から隠した資格・担保の計算を担う追加部品になる。日本での優先比較対象。
BOOSTRY / ibet for Fin
2021 年から稼働- 運営者が注文を見ない
- コンソーシアムの会員が見る
- 規則を外部者が検証できる
- 成り立たない
- 予約 → 原子的な決済
- 標準契約
- 決済が金額と価格を隠す
- 会員が見る
zkFMI との差 会員が運営する日本の ST ネットワークで、標準化された契約を持つ。Progmat と同じ追加部品の関係。
zkFMI
研究、ホスト 1 台、管理者 1 人- 運営者が注文を見ない
- 完全な注文を持つノードはない。7 ノード中 malicious(手順を破る)は最大 2 と仮定する。通信は観測できる
- 規則を外部者が検証できる
- zkPI 検証器と quote proof。述べられた注文集合について検証でき、市場全体についてではない
- 予約 → 原子的な決済
- メイカー予約とテイカー予約、バッチ DvP。証拠は smoke
- 決済が金額と価格を隠す
- 金額と価格は隠す。asset tag(資産の種類の識別子)とメタデータは、ネイティブのレールで公開
zkFMI との差 差は組み合わせにある。計算するノードから秘匿し、規則を外部者に証明し、予約を開かずに決済まで運ぶ。本番なし、独立した運営者なし、監査なし。
カードを横断して最初の二つの問いを読むと、この分野の形が見えてくる。機関向けの行は二つとも灰色である。運営者が信頼される世界のために作られているからである。基盤の行は一つ目が緑、二つ目が琥珀色である。業務を業務システムに委ねているからである。取引の行は分かれる。zkFMI は二つとも緑で、段階は灰色。この一行が立ち位置のすべてである。
九つの決定
比較は番号付きの九つの決定で締める。Canton を加えて、最大の労力で二度目の見直しを行った。九つすべてを維持し、いくつかは証拠が増えた。
| # | 決定 | 理由 | 帰結 |
|---|---|---|---|
| C01 | MPC、ZK、約定が正しく計算されたことの証明は、zkFMI を唯一のものにしない | Renegade の VALID MATCH は、入力の妥当性と照合の正しさを証明する。Canton では、関係する参加者が Daml の規則を再実行する。Prime Match は 2023 年に金融 MPC を稼働させた。 | 「市場の規則を証明できるのは我々だけ」という売り方は決してしない |
| C02 | 有望な軸は誰がどの秘密を知るかとどの規則と状態が同じ取引に束縛されるかである | Renegade の委任先 relayer は、担当するウォレットを読む。Canton のホスト validator は、その当事者のデータをすべて読む。OCLOB は参加者側で注文を分割する。したがって 2-of-7 の結託上限の下では、どの単一ノードも注文を持たない。 | まず、顧客がどの開示を受け入れるかを確かめる。計算主体そのものからの秘匿を必要とする案件を狙う |
| C03 | 価格形成は異なる。それは優位ではない | Renegade は、外部価格を用いた仲値でのクロスを文書化している。QOMM は秘匿の値付け規則の上での RFQ、OCLOB は確定した受付順の上での価格・時間優先である。 | RFQ、連続板、仲値でのクロスを混ぜた「速さの順位付け」をしない |
| C04 | zkFMI は秘密分散の安全性で一様に強いわけではない | Arcium の Cerberus は、honest な参加者が 1 者いれば秘匿性を保ち、逸脱があれば abort する。Zama の KMS は t < n/3 で鍵操作を完了する。OCLOB は 7 ノード中最大 2 ノードが malicious と仮定する。 | 秘匿性、正しさ、完了、運営者の独立性を、四つの別々の主張として述べる |
| C05 | 指図の標準、DvP、台帳をまたぐ調整は既に存在する | Ownera は intent、hold、オーケストレーションを記述している。Corda は契約状態と一意性を検証する。Canton の Token Standard(CIP-0056)は、allocation と、全脚の 1 取引での決済を標準化している。 | zkPI は、既存の契約に追加できる検証として提案する。原子性そのものは主張ではない。 |
| C06 | zkFMI は実際に機能する研究 MVP であり、成熟度に差がある | 1 つの取引での約定 2 件と、連続 2 ラウンドは、ホスト 1 台の上の smoke の証拠である。Canton には mainnet、商用のレポ基盤、複数社のパイロット、米国債の実取引、開始済みの PoC がある。 | 次の優先事項は、継続使用、障害下での一貫性、独立運用。相手側の成熟度を過小に述べない。 |
| C07 | 日本では、既存の証券業務と資金脚への接続が採用の条件になりうる | Progmat、ibet for Fin、Kinexys、Fnality は採用実績を公開している。MUFG と Progmat は 2026 年 8 月に Canton 上で JGB レポの PoC を開始した。JSCC、みずほ、野村は 4 月に JGB 担保の PoC を開始した。 | 最初の採用実証は連携であって、置き換えではない |
| C08 | 全系統の耐量子性は、まだ競争上の優位ではない | 単体のハイブリッドも、8 リポジトリすべての統合済み main ブランチも、commitment(値を隠したまま固定する暗号の部品)、証明、保存状態、すべての通信路を覆っていない。競合の PQC の状況は未確認であり、不在ではない。 | PQC は、境界ごとの移行計画として提示する |
| C09 | Canton は最優先の競合であると同時に、基盤または連携先の候補である | Daml が業務ロジック、権限付与、開示を持つ。synchronizer は公開でも私設でもよい。外部の MPC の結果や zkPI 検証器を Daml アプリに配線することは、設計上の推論であり、検証済みの実装ではない。 | 単体の DeFMI L1、QOMM、OCLOB、DeCCP の目標を維持する。Canton との連携は第二のゲートで評価する |
このサイトの他所で使う略式表現「他者は回路を証明し、我々は市場を証明する」は、quote proof が何を述べるかの説明である。それだけでは新規性の証拠にならない。比較は、これを新規性の根拠として使うのをやめた。
Canton、最も近い比較対象
Canton は一つの製品ではない。プロトコル、synchronizer の集合、当事者をホストする validator、第三者が書く Daml アプリケーションからなる。初期の草稿で最も多く見つかった誤りは、ある Canton の事例を Canton のすべての能力の証拠として読むことだった。そこで、まず層を分ける。
| 層 | 公式資料が確認していること | 区別すべきもの |
|---|---|---|
| Canton Network | 独立に運営されるアプリケーション、validator、複数の synchronizer が相互に接続されたもの。各 validator は、自身がホストする当事者の台帳断片だけを保存する。 | 一社の Canton 案件を、ネットワーク全体の能力が稼働している証拠と見ること |
| Daml アプリケーション | 契約が業務ロジック、signatory/observer/controller の役割、権限付与、開示を定める。validator 上で実行される。 | 基盤の性質と、各アプリケーションが実装する注文・与信・予約・清算の規則 |
| validator(participant ノード) | 当事者をホストし、その契約を保存し、自分宛ての取引 view を復号して検証する | 公開チェーンでの「validator」の意味。そこでは全 validator が全取引を読む |
| synchronizer | sequencer が暗号化されたメッセージを順序付けて配送する。mediator が関係する validator から確認を集め、commit か reject を宣言する。どちらも Daml の内容は検証しない。 | 順序付けと確認は、業務ロジックや入力の正しさの検証とは別のもの |
| Global Synchronizer | Super Validator が運営する公開の synchronizer。順序付けは CometBFT、耐障害は f = ⌊(n−1)/3⌋。通信量は Canton Coin の焼却で支払い、参加にはスポンサーが必要。アプリケーションは代わりに私設の synchronizer を使ってもよい。 | すべての Canton アプリケーションがこれを通るという想定 |
| アプリケーション提供者 | 台帳上の Daml と、台帳外のロジック、認証、提出を供給する | プロトコルの保証と、提供者が入力を正しく受け付け、選び、提出するという信頼は別のもの |
誰が何を読むか
Canton は取引を view に分け、それぞれを開示先(informee)の participant 向けに暗号化する。無関係な当事者には何も届かず、synchronizer は復号できない。これが取引内部の部分ごとの秘匿(sub-transaction privacy)である。平文は、必要とする当事者だけと共有される。このスタックが目指す保証は別のものである。許容する結託の上限の内では、計算するどのノードも完全な注文を持たない、という保証である。
| 主体 | 読める | 読めない |
|---|---|---|
| 当事者(signatory、observer、controller) | 自身が開示先である view。divulgence(付随する開示)により、利害関係者でない契約が見えることがある | 無関係な view の内容と当事者メタデータ |
| 当事者自身の validator | 信頼モデルは「あなたのデータをすべて見て、あなたを妨げることもできる」と述べる。外部の当事者鍵を使えば署名権限は当事者側に残るが、可視性を取り除くとは記述されていない。 | |
| 取引相手 | 共有された view の平文。漏らさないと信頼される | |
| アプリケーション提供者、台帳外の部品 | 実装次第。台帳外の照合エンジンが平文の注文を扱うことがある。 | |
| sequencer | 暗号化された封筒、受信者、順序、サイズ、時刻 | 内容 |
| mediator | 各 view の開示先一覧、確認方針、各承認・却下 | 内容 |
| 無関係な当事者と validator | 何も読めない | |
| 監査人 | observer として設計に組み込まれていれば、関係する view の平文 | 秘密を受け取らずに、命題の持ち運べる証明を得ること。これは文書化された標準経路にはない |
これは理由が述べられた設計上の選択であり、文書の欠落ではない。2020 年の Canton ホワイトペーパーは、MPC を含む高度な暗号は計算コストが高いとし、Canton は代わりに、より強い信頼の仮定の下で可視性を限定すると述べる。2025 年の公式記事は、一般的なプライバシーのためのゼロ知識証明を実験的と呼ぶ。Canton のアプリケーションが外部の MPC を呼ぶことや、外部の証明を検証することを禁じるものはない。したがって差は、文書化された標準経路とこのスタックの経路との間にある。「Canton では不可能」とは書けない。
軸ごとに
| 軸 | Canton、確認した範囲 | zkFMI、現在の位置 | 判定 |
|---|---|---|---|
| 誰が秘密を知るか | 無関係な当事者と synchronizer からは隠れる。ホスト validator と権限のある当事者は、関係する view を読む | 参加者側で分割し、どの MPC ノードも完全な入力を持たない。3 ノード以上の結託と通信の観測は、限界として残る | 差を示せる ただし顧客が自社 validator への開示で満足するなら、差はゼロに縮む |
| 計算主体からも隠れた計算 | 標準経路は view を復号し、Daml を平文で再実行する | 7 ノードの MPC、malicious は最大 2、研究実装 | 候補 Canton 上の外部 MPC は設計上の選択肢で、検証済みの実装はない。一つの業務、結託上限、可用性、コストの下で比較するまで、優位は決まらない |
| 資格、与信、予約 | Daml は三つとも表現し検証できる。予約に基づく決済は、CIP-0056 の allocation により平文のまま既に標準化されている | DeKYX の資格、メイカー予約とテイカー予約、端から端までの経路にわたる保証枠 | 機能の差ではない 差は、注文と予約の対応関係が照合ノードから隠れているか、それとも登録簿・アプリ・validator に読まれるかにある |
| 市場の規則 | 当事者が決定的な Daml ロジックを検証する。同等の連続指値板や RFQ のアプリケーションは未確認である。文書化された唯一の取引アプリは AMM で、swap をチェーン外で提出する | QOMM の RFQ と OCLOB の価格・時間優先を MPC 内で計算し、zkPI に束縛する | Canton 上に構築可能 原理的には可能。存在は示されていない |
| 入力集合 | 提出された取引が参照する契約を束縛する。台帳外の受付の完全性は、アプリケーションの境界にある | 受付順と注文集合を証明に束縛することを目指す。受付前の検閲は依然として可能 | どちらも「市場全体」を証明しない。比較するなら、受付の commitment と対象集合を比較する |
| 決済の原子性 | 共通の synchronizer 上では、アプリケーションをまたぐ DvP を 1 つの Daml 取引で行う。synchronizer をまたぐ場合は、再割当ののち原子的に決済し、その間は資産が保留になる | ネイティブのレールでの複数約定のバッチ決済について、smoke の証拠 | zkFMI は主張しない 外部台帳を含む同じ脚で比較するまで |
| 第三者による検証 | 関係する validator が自身の view を検査する。監査人は observer になれる | zkPI 検証器が、秘密なしに、定義された命題を検査する | 価値の可能性 ただし排他的ではない。zkPI 検証器は Daml アプリケーションの内部にも置けるからである |
| 運用上の信頼 | 自社または外部委託の validator、取引相手、アプリケーション提供者、synchronizer、Foundation の統治 | MPC ノード、コーディネータ、読み戻しサービス、DeFMI の検証者。鍵と運営者の独立性は受入済みでない | 秘匿性、正しさ、可用性、検閲、復旧について誰が責任を負うかを比較する。ノード数を比較するのではない |
| 成熟度、性能、法的枠組み | 2024-07 から mainnet、プロトコル更新が稼働、商用のレポ基盤、米国債の実取引 1 件、日本での PoC 3 件が開始 | ホスト 1 台の研究 MVP、smoke の証拠 | Canton を過小に述べない 同一条件下の性能、需要、認可は両側とも未確認 |
| 耐量子 | 未確認 | 8 リポジトリすべての統合済み main ブランチにあるハイブリッド署名と KEM(鍵カプセル化、鍵交換の部品)。ZK の関係式は古典 | 未確認と記す。どちらの方向にも主張しない |
事例は一次資料が述べる段階のまま
| 事例 | 一次資料での段階 | 一般化してはいけない先 |
|---|---|---|
| Global Synchronizer | 稼働開始 2024-07-01。Canton 3.5 の logical synchronizer 更新が 2026-06-29 に稼働 | 個別アプリケーションの利用状況、SLO、認可 |
| Canton Network Pilot | 2024-03-12: TestNet 上で 22 の dApp、350 件超の模擬取引。参加者数は要約で 45、役割別の本文で 36 | 本番資産や、継続的な商用取引 |
| Broadridge DLR | 2023 年に Canton へ移行、資金はチェーン外に置いたまま(2024 年の顧客事例)。2025 年 8 月の自己申告で、1 日平均のレポが 2,800 億ドル($280bn) | Global Synchronizer の利用、チェーン上の資金、秘匿の板 |
| Tradeweb | 2026-07-01: 取引 1 件。トークン化した米国債と USDCx を、チェーン上で同期して決済 | 持続的な処理能力や、完全なライフサイクル |
| DTCC | DTC が保管する米国債の一部を Canton 上で発行する計画。MVP は 2026 年上半期に、管理された本番環境で予定。完了は未確認 | 商用開始 |
| JSCC / みずほ / 野村 | 2026-04-20: デジタル JGB 担保管理の PoC。JGB の振替法上の法的地位は保つ。金融庁の Payment Innovation Project に選定 | 完了、終了日、商用化 |
| MUFG / Progmat / Secured Finance | 2026-08-13: JGB レポをチェーン上に載せる PoC。口座管理機関がチェーンと並行して振替口座簿を更新する。資金脚はトークン化預金またはステーブルコイン | 完了や法的な提供 |
| Progmat / DCC working group | 2026-05 に発足、報告は 2026-10 を目標 | 基盤の選択 |
日本の PoC は、この計画にとって特に重要である。これらは担保とレポの業務の中にあり、業務システムの調査はその業務を最上位に置いている。また、JGB を振替制度の中に留めている。規制のページが日本での配置に必須だと述べるとおりである。したがって戦略は、それらの業務の置き換えを提案しない。その内側で、計算主体からも隠す必要のある入力を探す。すなわち注文、レート提示、担保配分である。
グループごとに
表の裏にある注記を、Canton 以外の 17 件について記す。優先度は、自作・購入・接続のどれを選ぶかの判断にどれだけ関わるかの判定であり、市場シェアの順位ではない。「連携候補」は、zkPI の行き先として妥当という意味であり、既存の連携ではない。連携は一つも存在しない。
機関向け台帳、資金脚、接続性
| 対象 | 競合する仕事 | 秘匿性と信頼境界 | 段階 | 扱い |
|---|---|---|---|---|
| R3 Corda | 資産状態と機関間の業務 | 関係する当事者間の共有。非検証型の notary は入力状態の参照を見るが、内容全体は見ない | CSD Prague の DLT 決済に採用。Solana 向けの別製品「Corda protocol」は 2026 年上半期に計画されていたもので、台帳製品ではない | 優先比較対象、連携候補 |
| Kinexys(J.P. Morgan) | 銀行の決済、トークン化、ファンドの資金の流れ | 銀行が運営する。銀行から入力を隠すこととは別のもの | JPM Coin on Base と、最初のファンド資金移動の取引を 2026-04-28 に発表 | 機関向けの比較対象、資金脚の候補 |
| Fnality | 機関向けデジタル資金 | 中央銀行口座の資金に裏付けられる。秘匿の価格形成は焦点ではない | イングランド銀行の FMI 報告に載るポンド建てシステム。制限の下で稼働 | 資金脚の候補 |
| Partior | 国際送金、FX の PvP | 参加銀行のネットワーク。秘匿された市場計算は未確認 | 稼働中の決済事例。DvP は概念実証 | 資金脚と PvP の候補 |
| Ownera / FinP2P | 台帳をまたぐ資産の販売と決済指図 | 機関ごとのルータ、アダプタ、参加者間の合意。基盤となる台帳が hold と原子的決済をできるかに依存する | API とオーケストレーション計画を公開 | 優先比較対象。連携設計の参照先。zkPI の位置に最も近い |
| Swift shared ledger | 銀行間の決済調整、トークン化預金 | Swift が運営する共有層。その脇に銀行の台帳があり、最終決済は既存システムを通す | 2026-07-09 に初期利用可能。銀行が実パイロットを準備中 | 動向を追う |
| Chainlink CCIP、CRE、ACE | 外部データ、ポリシー、クロスチェーン実行 | オラクル・ネットワーク、TEE、分散鍵生成。TEE の内部の平文は、MPC や ZK とは別の場所に信頼を置いている。「検証可能」という語を何に付けようと、それは変わらない | プライバシー機能と事例を 2026-05 に記述 | zkPI の連携候補かつ比較対象 |
| Progmat | 日本のセキュリティトークンの発行と管理 | 発行者、信託、販売会社の役割。それらすべてから入力を隠すことは未確認 | ST 案件一覧。Corda から専用 Avalanche L1 への移行完了を、提供者が発表。外部販売のないトークン化投資信託の実証、チェーンは明記なし | 日本での優先比較対象、連携候補 |
| BOOSTRY / ibet for Fin | 日本の ST、コンソーシアム運営 | 会員が運営するネットワーク、標準契約 | 2021-06 に運用開始。コンソーシアムのページの本文は取得できなかった | 日本での優先比較対象、連携候補 |
このグループに共通する教訓は、障壁は暗号ではなく、接続性と顧客関係だということである。zkPI が何かを加えるのは、受け取る台帳が証明を検証する場合だけである。署名やダイジェストを受け入れるだけの受け手は、保証を署名者への信頼に戻してしまっている。業務システムのページにある指図の発行元がすべて解かねばならない六つの問題が、行き先の台帳ができなければならないことの一覧である。
秘匿注文と秘匿資産の取引
| 対象 | 市場と検証 | 秘匿性と信頼境界 | 段階 | 扱い |
|---|---|---|---|---|
| Renegade | 二者間の MPC が協調 SNARK を生成する(VALID MATCH: 入力の妥当性、照合の正しさ、暗号化された出力)。外部価格を用いた仲値でクロスする。残高はチェーン上で更新 | 顧客が委任した relayer は、その顧客の注文と残高を平文で読む。他の relayer は読まない。顧客は自分で relayer を動かしてもよい | Arbitrum One 上の mainnet | OCLOB の優先比較対象。差は三つ。委任の境界。確定した受付順の上での価格・時間優先か、仲値でのクロスか。約定から予約、決済への連続性。資格のある注文が一つも省かれていないことを Renegade が証明するかどうかは、監査しておらず、主張しない。 |
| Prime Match(J.P. Morgan) | 銀行とその顧客の間の MPC 在庫照合 | 著者が設定した、銀行と顧客の脅威モデル。このスタックのノード構成ではない | 2023 年の論文で稼働を報告。2026 年の状況は未確認 | 先行研究。「初の金融 MPC」というあらゆる主張を退ける。詳細は先行研究のページ。 |
| Penumbra | shielded pool(秘匿残高のプール)、ブロック単位のバッチ swap | 現行仕様では swap の入力資産と数量が公開。封印入札のバッチは将来の機能と明記 | 仕様を確認 | 市場設計の動向を追う。ウォレットの連結不能性と、実行前の価格の秘匿は別の行であり、混ぜてはならない。 |
| Dusk | 秘匿移転と選択的開示を持つ、規制資産向けの台帳 | モデル次第。暗号資産交換業者向けの連携ガイドは、公開アカウントのモデルを定める | mainnet の仕様。NPEX との協業 | 証券業務の動向を追う。提携先の免許は、チェーン上のアプリケーションには及ばない。同じ基準は DeCCP にも当てはまる。そのコードは免許を持つ CCP ではない。 |
秘匿計算と業務システムの基盤
| 対象 | 提供するもの | 秘匿性と信頼境界 | 段階 | 扱い |
|---|---|---|---|---|
| Arcium | Solana 上の汎用 MPC 実行環境 | Cerberus: 不正多数派を許す。honest な参加者が 1 者いれば秘匿性を保ち、逸脱を検知して abort する。可用性は別の条件 | mainnet alpha | 優先比較対象であり、調達の選択肢でもある。「我々は 7 ノード、相手は中央集権」は成り立たない。同じ業務を Arcium 上に構築することが、評価すべき代替案である。 |
| Zama | 暗号化状態上の FHE、秘匿トークン、閾値 KMS | 計算、復号権限、鍵管理が分離している。KMS は強い honest majority(t < n/3)を仮定する。コプロセッサは、入力の知識証明、FHE 評価、commitment、署名を分離する | mainnet 2025-12-31、封印入札オークションが 2026-01 | Arcium と並ぶ基盤の比較対象。その入力証明を、業務結果全体の証明として読まないこと。外部検証を持つのは zkFMI だけだと主張しないこと。 |
| Aztec | クライアント側で証明する、Ethereum L2 上の秘匿・公開アプリケーション | 秘匿の witness はクライアントに留まる。複数企業の入力に対する共同計算ではない | Alpha V5。証明系の重大な脆弱性を 2026-08-07 に開示。修正は V6 で予定、完了は未確認 | 動向を追う。このスタックにも独立監査はない。競合が alpha 段階であることから得るものは何もない。 |
| Hyperledger Fabric | 許可型台帳、private data collection | 実データは認可された peer へ、ハッシュはチャネルへ。orderer は秘匿データを受け取らない。どの組織が読むかを限定するが、認可された peer から入力を隠しはしない | 仕様を確認 | 社内の代替案。全員からの秘匿が不要なところでは、既存の統治に Fabric を足す方が明快な選択になりうる。zkFMI の根拠は、アクセス制御が届かない境界から組み立てなければならない。 |
同じ基準をこのスタックに適用する
比較は、この計画自身の文書も同じ規則で読んだ。結果は基準ファイルに SHA-256 で固定した。後から文書がずれても、結果を遡って良くすることはできない。
| 項目 | 判定 | 証拠と限界 |
|---|---|---|
| 注文と MPC ノードの分離 | 参加者側経路の設計と実装を確認 | 7 ノード。コーディネータは注文を決して見ない。ブラウザ互換のデモは依然として平文を持つ |
| 複数約定の決済 | 既存の artifact(実行が残した記録物)から確認 | 約定 2 件、取引 1 つ、確認 14 件。5 つの検証者と再起動をまたいでルートが一致。比較のために再実行はしていない |
| 連続取引 | smoke のみ | 2 ラウンドと約定 3 件。取消、期限切れ、戻った資産の再利用、7 つの MPC ノードの再起動。以前に却下された実行は台帳に残している |
| 台帳の finality | 読み取りサービスへの信頼が残る | 各ノードは読み戻すが、独立した合意の証明は検証しない |
| 決済の秘匿性 | すべてのフィールドではない | ネイティブのレールの資産識別子と決済メタデータは公開 |
| 身元と資格 | scope 内で仮名 | DeKYX は発行者に対して連結不能ではない。認証された KYC 製品でもない |
| 清算 | 研究段階の状態機械 | DeCCP は保管機関でも、免許を持つ清算機関でもない |
| 暗号の安全性 | 修正済みの欠陥と、受入済みでない保証は別 | note 証明の欠陥が見つかり、修正した。Triptych への依存は実験的。独立監査なし |
| QOMM の経済性 | 確認実験は未通過 | 合成データでの smoke。価格改善や顧客利益は主張しない |
| 独立運用 | 成り立たない | ホスト 1 台、管理者 1 人、WAN なし |
この計画が使う言い回しと、使わない言い回し
| 文 | 状態 | 条件、または代わりに言うこと |
|---|---|---|
| 「秘匿された注文受付、価格・時間優先の照合、事前予約、証明付き決済をつなぐ研究実装」 | 使う | 経路と、ホスト 1 台という範囲を明示して |
| 「2 件の約定を 1 つの取引で原子的に決済した」 | 使う | 実行の条件と artifact を付けて。処理能力の証拠としては決して使わない |
| 「述べられた注文集合、規則、決済が一致することを外部者が検証できるようにすることを目指す」 | 条件付き | 検証器が検査する命題と、署名者と読み戻しに残る信頼を名指しして |
| 「初の金融 MPC」/「唯一の MPC と ZK による決済」 | 使わない | Prime Match と Renegade が先行する |
| 新規性の証拠としての「競合は回路を証明し、我々は市場の規則を証明する」 | 使わない | Renegade は照合を証明する。Canton の参加者は Daml の規則を検証する。何が異なるかは、具体的な関数、集合、認可、決済を名指しして言う。 |
| 「Canton は注文、資格、予約を扱えない」/「Canton には原子的な DvP がない」 | 使わない | どちらも存在する。文書化された個別のアプリケーションを比較する |
| 「7 ノードだから Arcium より強い」 | 使わない | honest な参加者についての仮定が異なる |
| 「秘匿台帳は資産の種類、通信、身元を含むすべてを隠す」 | 使わない | ネイティブのレールの asset tag は公開。通信は観測できる。DeKYX は発行者からは連結できる |
| 「本番の FMI または CCP」/「全系統が耐量子」/「競合より速い」 | まだ使わない | それぞれ、機関による証拠、すべての暗号経路を覆う証拠、同一条件下の計測が必要 |
差を主張する前に zkFMI が示すべきこと
比較から導いた、この計画自身の検証課題である。他者の弱点の一覧ではない。
| 候補となる命題 | 必要な証拠 | 比較対象 |
|---|---|---|
| 注文と値付け規則を運営者からも隠す | 参加者側のシェア生成から MPC、決済までで、可視性を持つ主体の一覧。結託の条件。すべての平文の地点。鍵の管理者 | Renegade、Arcium、Prime Match、Canton |
| 執行規則を事後に検証できる | 注文集合、受付順、資格、価格・時間優先、部分約定を束縛する命題と、独立した検証手順 | Renegade、Penumbra、Zama 上の市場アプリ、Canton 上の Daml アプリ |
| 計算結果と引渡しが一致する | 同じ commitment が、計算、指図、予約、両脚の消費を通して束縛される。再試行や二重使用で状態が変わらない | Ownera、Corda、Chainlink、Canton Token Standard |
| 機関が採用できる | 発行、保管、登録、資金脚の責任。復旧。監督当局への開示。参加と退出。法的 finality | Kinexys、Fnality、Partior、Swift、Progmat、ibet for Fin、Dusk、Canton |
| 長期の秘匿性と検証可能性 | 署名、KEM、commitment、証明、TLS、保存データを分けた脅威モデルと、移行・失効・再検証の経路 | 採用するすべての構成 |
比較が変えたこと
九つの決定から導かれる戦略は短い。最初の用途は、デジタル証券の機関向け流通取引である。ただし、板の中での順番が確定するまで、注文を計算主体から隠さなければならないものに限る。計算主体とは、組織自身の validator、アプリケーション運営者、照合エンジンである。最初に提供するものは連携モジュールである。顧客が既に運用する台帳に、秘匿照合、事前予約、zkPI 検証器を加える。単体の DeFMI L1 は参照経路として維持する。比較対象は、市場と決済では Canton と Renegade、秘匿計算では Arcium と Zama、連携設計では Ownera である。
その前に置く最初のゲートは、実装ではなく顧客への問いである。自社の validator と照合エンジンからも入力を隠す必要があると、文書に記す組織が少なくとも一つあるか。どこでも「自社 validator への開示は受け入れられる」という答えなら、その顧客には Canton 型の設計で足り、最初の用途の選択は誤りである。比較はこれを、戦略を見直す条件として名指ししている。この条件はまだ検証されていない。
これらの結論が変わるとき
- 連続取引、取消、期限切れ、競合、復旧、独立運用についての受入の受領証(C02、C06)
- 同じ受付集合、順序付け、資格、予約、決済を、Canton または Renegade の上に明示的に対応付けたもの(C01、C03、C09)
- 同じ端から端までの経路を Arcium または Zama 上で動かし、出力、秘匿の範囲、コスト、障害時の挙動の差を計測したもの(C04)
- 行き先の台帳が、API、hold、commit、abort、読み戻しと、法的責任の配分を確認したもの(C05、C07)
- 署名と鍵交換以外の部品を覆う、移行の受領証(C08)
- ベンダーのバージョン、段階、修正告知の変更。変更があれば、再利用の前に出典を読み直す。
この比較がしなかったこと
この比較では、Canton ノードを動かさず、競合のアプリケーションを使わず、何もベンチマークせず、誰のコードも監査せず、顧客に聞き取りをせず、外部システムに何も書き込んでいない。一部の資料は全文を読めなかった。Renegade のホワイトペーパーはサーバーエラーを返した。Canton のパイロット PDF は取得上限を超えたので、同じ内容の公式発表に置き換えた。Tradeweb の投資家向けページはタイムアウトしたので、Canton による再掲に置き換えた。ibet for Fin のコンソーシアムのページは、検索の要約しか得られなかった。置き換えはそれぞれ出典文書に記録した。読んでいないものを読んだものとして扱っていない。比較には日付がある。2026-09-05 の段階ラベルは、その日の状態を記述する。
確認した一次資料(抜粋。すべて 2026-09-05 に開いた)
| 対象 | 資料 |
|---|---|
| Canton | アーキテクチャ · プライバシーモデル · 合意 · 取引のライフサイクル · 信頼モデル · 複数 synchronizer · synchronizer をまたぐ DvP · Splice / Global Synchronizer · 2020 年ホワイトペーパー · CIP-0056 Token Standard · Splice の allocation インタフェース · 稼働開始 2024-07-01 · Canton 3.5 LSU · パイロット 2024-03-12 · Broadridge 2025-09-10 · Broadridge 顧客事例 · Tradeweb 2026-07-01 · Canton Foundation への改称 |
| 日本 | MUFG JGB レポ PoC 2026-08-13 · JSCC / みずほ / 野村 PoC 2026-04-20 · Progmat / DCC WG · Progmat ST 一覧 · Progmat 投資信託の実証 · Progmat 移行計画 · ibet for Fin · ibet for Fin 開始 2021 |
| Renegade、Prime Match | relayer · 協調 zkSNARK · ピアツーピア・ネットワーク · リポジトリ · Prime Match、arXiv 2310.09621 |
| Arcium、Zama、Aztec、Fabric | Arcium の MPC プロトコル · Zama mainnet · Zama KMS の概念 · Zama コプロセッサ · Aztec V5 告知 · Fabric の private data |
| 台帳と接続性 | Corda、CSD Prague · Corda の非検証型 notary · Kinexys のマイルストーン · イングランド銀行 FMI 報告 2025–26 · Partior · Ownera のオーケストレーション · Swift shared ledger · Chainlink のプライバシー · Penumbra のバッチ swap · Dusk の交換業者向け連携 |