9月19日Raylsが（「プライバシーには代償がある」）という記事を投稿しました。タイトルには「honest math」と書かれていて、記事全体で提示されたのはたった1つの数値レンジです。1つの証明は数百ミリ秒から数秒かかるというものです。私は数週間、Raylsのプライバシー・アーキテクチャを書き続けていますが、今回は皆さんに新しい内容を共有します。公開されている証明コードをダウンロードして実際に数十回動かしてみたので、この面白い結論を皆さんに共有します！
まず、ブログで何を言っているかを説明します。その核心の主張は2つの文に要約できます。1つ目はコストがどこにあるかです。機密取引は透明な取引よりも高く、その高い部分の正体はゼロ知識証明の生成にあります。検証はむしろ安く、ベースとなる機密送金の証明は、一般的な商用ハードウェア上で数百ミリ秒から数秒かかるとのことです。2つ目は何を問うべきかです。機関はTPSだけを気にするべきではなく、自分たちが必要とするプライバシーと監査（監査レベル）の要件を満たし、さらに実際の業務負荷に直面したときのスループットはどれくらいかを問うべきだ、というのがブログの見方です。ブログでは、銀行間決済の量は大きくなく、完全に機密な決済システムの能力の範囲内だとしています。
この記事でやっていることはとてもシンプルで、ブログ自身が提起したこの問題を、Enygmaの公開コードに投げてみた、というだけです。以下に「ブログが言う」とあるのは原文の主張で、「私が測った」「私が計算した」とあるのは私自身の結果と推算です。混同せずに見てください。
どうやって測ったか
ゼロ知識証明は、数学的な証明書のように考えることができます。支払者は残高や金額を公開せずとも、ネットワークに対して「この取引は正しい」ことを証明できます。Enygmaが使っている証明システムはGroth16で、証明生成サービスのコードはGitHubのrayls-sovereign-gnark-apiリポジトリでオープンソース化されています。READMEでの位置づけは、Privacy LedgerとPrivate Network Hubの裏側で使う証明インターフェースです。
私が測ったのは、mainブランチの2026年9月22日の最新コミット67c4c26です。回路と証明コードは1行も変更されていません。私が追加で書いたのは、リポジトリ自身の証明関数を呼び出すためのテストファイルだけで、入力した取引データもリポジトリに付属のテストセットから取得し、k=2とk=6をそれぞれ1組ずつ使いました。
ここでのkは匿名集合の大きさです。回路コードを見ると、1回の送金はk個の参加者それぞれに対して金額コミットメントを1つずつ生成させ、送信者はその中に隠れます。第三者は誰が誰に支払ったのか分かりません。kが大きいほど深く隠せるので、回路も大きくなります。リポジトリに付属の負荷テストスクリプトで使っているのはk=6です。
鍵は、同じgroth16.Setupを自分のローカルで生成しました。これでは所要時間には影響しません。証明時間は鍵の具体的な値ではなく、回路構造に依存するからです。リポジトリのREADMEにも、そこにある鍵一式自体が「単独Setupによる開発・テスト用の成果物」であり、多者間の信頼できるセットアップ（可信设置仪式）の結果ではない、と明記されています。プロダクションへのデプロイには別途儀式が必要で、これはブログの「Groth16には可信设置が必要」という主張とも整合しています。
テスト環境は、単一コアのLinux仮想マシン、Intel Xeon 2.1GHz、メモリ3GBです。各条件で連続して20個の証明を生成し、その後数分おいて全テストをもう一度同じように（第2ラウンドとして）完全に実行しました。
測定できた数
第2ラウンドの結果：k=6の証明は20回の中央値1.96秒、最速1.94秒、最遅2.12秒；k=2の中央値は0.96秒です。第1ラウンドはそれぞれ1.97秒と0.96秒で、2ラウンドの差は1%未満です。証明の検証は1回あたり1.9ミリ秒です。
この一連の数値は、ブログが提示した範囲に収まっています。より注目すべきは、生成と検証の比率です。1.96秒対1.9ミリ秒で、およそ1,000対1。ブログは、時間の大半は生成にかかり検証は安いと言っていますが、この比率によって「大半」が具体的な倍率として見えるようになります。
私は逆向きのチェックもしました。テストセットには、あえて改ざんしたデータが2組含まれています：k=2の組では送金額を0から10へ変更し、k=6の組ではハッシュ値を1つ改ざんしました。どちらも証明生成段階で拒否され、分別して第517条と第1085条の制約不成立として報告されました。つまり証明は生成できません。もちろん、これは回路に脆弱性がないことを意味するものではなく、明らかな改ざんの2種類が確実に弾かれることを示すだけです。
2つのブログにない細部
1つ目の細部は回路規模です。参加者が1つ増えるごとに制約数は固定で8,112増えます。k=2の37,140から、k=6の69,588まで一直線に増加しています。ただし証明システムは回路に計算用の空間を割り当てる際、2のべき乗に丸めます。そのためk=2からk=5までは65,536以内に収まり、k=6では4,052を超えてはみ出し、計算規模が直接131,072へと倍増します。
根拠は、証明鍵ファイルのサイズです。k=2からk=5までは、各段で鍵サイズが安定して918,382バイトずつ増えます。k=6では一気に3,015,534バイト増え、これは前までの各段の3倍以上です。所要時間の傾向も一致しています。制約数はk=2からk=6で87%増え、証明時間は104%増えました。境界をまたぐこのステップで追加でどれくらい時間がかかるかは、k=3からk=5の取引データが必要で、リポジトリは現時点でk=2とk=6の2段しか用意されていないため、方向性しか確認できません。もし本番環境で使うのがk=6なら、この境界の反対側にちょうど座っており、k=5からk=6へ切り替えるコストは、前の数段間より大きくなるはずだ、というのが私の推測であり、ブログの主張ではありません。
2つ目の細部は整合性です。公開ソースから生成した5段階の証明鍵について、ファイルサイズとリポジトリに記録されている公式ビルド産物のサイズが、バイト単位で完全に一致していました。k=6の検証鍵も同じです。鍵の中身は当然毎回変わります。Setupのたびに毎回ランダムに再生成されるからです。しかしサイズは完全に一致しており、公開ソースでコンパイルされた回路構造と公式ビルドが同じ一式であることを示しています。前の記事でAxylの監査について書いたときにも触れましたが、公開リポジトリと監査時の非公開バージョンの間には、追跡できない履歴が一部あります。今回、証明サービスの側では少なくとも「ソースと公式ビルド」の部分は合っています。公式ビルドと本番デプロイが一致しているかどうかは、公開資料だけではまだ答えられません。
ブログの問題を実際の負荷に当てはめる
前の投稿に接続します。前回私は、15,000+ TPSに関するいくつかの数字の出所を分解していましたが、それらはAxylのコンセンサス層の記述です。今回は別の層を測定しました。つまり、1件の機密取引について送信側で先に消費される証明時間です。2つの層の数字は足し算もできず、互いに置き換えることもできません。
ブログが挙げた規模は次のとおりです。大手代理行の関係では1日数千件、中央銀行クラスのトークン化されたリアルタイム総額決済サービスでは1日数万件の大口送金です。私は、2つの既存システムの公開データに置き換えました。米連邦準備制度 Fedwire Funds Serviceの2025年の日次平均は869,187件、英国CHAPSの2025年年間日次平均は210,483件で、どちらもブログの例に比べて数十倍、数倍です。
以下は私の計算で、ブログの主張ではありません。単一コアで実測したところ、1.96秒でk=6の証明を1つ生成できます。1コアあたり1日最大約44,000個生成可能です。Fedwireの2025年の日次平均取引件数をすべてk=6の証明に置き換えると、必要なのは約473コア時間で、これは「20コアが毎日昼夜休まず」くらいの規模です。CHAPSは約115コア時間で、5コア未満です。イングランド銀行が2021年に出した紹介資料には、CHAPSの単日取引記録は2018年3月29日の320,034件で、当年の日次平均の約1.7倍とあります。このピーク値で見積もっても、必要なのは約174コア時間にとどまります。
この推算の前提は明確にしておく必要があります。これは「各証明が1コアを占有する」として換算しています。証明同士は互いに独立しているため、別々のコアに振り分けて同時生成できます。計算しているのは送金の証明そのものです。入金、出金、そしてDvPは別の回路です。ネットワーク伝送やオンチェーン決済も、この計算の範囲には含まれていません。さらにブログでは、証明は送信側で生成される、としています。つまり負荷は自然に、各機関の自社ノードに分散され、1台のマシンに集約されるわけではありません。
それで私の結論はこうです。ブログは「銀行間決済量が、機密決済システムの能力範囲内である」という判断をしていますが、実際の規模に置き換えてもその判断は依然として成り立ちます。ブログが挙げた量は現実のシステムより小さいものの、現実の数字をそのまま結論に代入しても成立します。これはむしろ、原文の例の説得力を強めています。小売決済の段落では、ブログ自身がそれが本当のボトルネックだと認めていますが、今回の数字はその判断を変えません。
この数値はどう使うべきか
今回の数字はすべて単一コアで出したもので、多少保守的な参考として見てください。理由はコードにあります。gnarkで証明を生成するとき、最も重い多重スカラー乗算はCPUコア数に応じて複数のタスクに分割されて同時に計算されます（backend/groth16/bn254/prove.goで直接runtime.NumCPU()を読み取っています）。機関のサーバは通常マルチコアなので、同じ証明はより多くのコアで計算され、ここでの単一コア結果より所要時間は短くなるはずです。どれくらい速くなるかは、コア数と単一コア性能次第です。
この記事の測定範囲は、送金回路そのものの証明生成にかかるコストです。完全なHTTPサービスの通信経路には、JSON解析やネットワークのオーバーヘッドなど他にも種類がありますが、入金・出金およびDvPはそれとは別の種類の回路です。鍵のサイズが一致していることは回路構造が同じであることを示しますが、鍵の中身が同一であることまでは意味しません。この点は先に説明しました。
私の見解
ブログのタイトルはhonest mathですが、本文で提示されている数字はたった1つの区間だけでした。今回走らせた結果、区間は正しいですし、銀行間決済の部分に関する結論も成り立ちます。
私がもっと見たいのは次のステップです。Axylのベンチマークページには、4ノード委員会や512バイト取引といった条件が明記されています。Enygmaの証明性能についても同じ扱いをしてほしい：次に数字を公開するときは、kの値とハードウェア構成も併記すれば、機関は私のように自分で再現できます。これは、ブログ最後が言っている「本番の検証に耐え得る」性能主張そのものです。再現は難しくありません。スクリーンショットの中のコマンドが完全な手順です。
参考元：Rayls公式ブログ（Privacy has a price: the honest math behind confidential settlement at scale）（2026年9月19日）；GitHub raylsnetwork/rayls-sovereign-gnark-api、コミット67c4c26（2026年9月22日に読み取り、実測）；米連邦準備制度 Fedwire Funds Service 年次統計（2026年1月26日更新）；イングランド銀行 Payment and settlement statistics と（A brief introduction to RTGS and CHAPS）（2021年版）。