9 月 19 日 Rayls 发了一篇《Privacy has a price》，标题里写着 honest math，可整篇只给了一个数字区间：一个证明要几百毫秒到几秒。我连着几周都在写 Rayls 的隐私架构，这次给大家分享下新内容，我把它公开的证明代码拉下来，实际跑了几十次，给大家分享一下这份有趣的结论！
先说博客讲了什么。它的核心论点可以压缩成两句话。第一句是成本在哪：机密交易比透明交易贵，贵在生成零知识证明，验证反而便宜，一个基础机密转账的证明在普通商用硬件上要几百毫秒到几秒。第二句是该问什么：机构不该只问 TPS，而该问在自己需要的隐私和审计水平下、面对真实业务负载时吞吐量是多少，博客认为银行间结算的量不大，完全在机密结算系统的能力范围之内。
这篇文章做的事很简单，就是把博客自己提出的这个问题，拿去问 Enygma 公开的代码。下文凡是写「博客说」的，是原文的主张；写「我测到」「我算的」，是我自己的结果和推算，请分开看。
我怎么测的
零知识证明可以理解成一张数学凭证：付款方不公开余额和金额，也能向网络证明这笔账是对的。Enygma 用的证明系统叫 Groth16，生成证明的服务代码开源在 GitHub 的 rayls-sovereign-gnark-api 仓库，README 对它的定位是 Privacy Ledger 和 Private Network Hub 背后使用的证明接口。
我测的是 main 分支在 2026 年 9 月 22 日的最新提交 67c4c26。电路和证明代码一行没改。我只另写了几个测试文件，用来调用仓库自己的证明函数，喂进去的交易数据也取自仓库自带的测试集，k=2 和 k=6 各一组。
这里的 k 是匿名集大小。从电路代码看，一笔转账会给 k 个参与方各生成一个金额承诺，发送方藏在其中，旁人看不出是谁付给了谁。k 越大藏得越深，电路也越大。仓库自带的压力测试脚本用的就是 k=6。
密钥是我在本机用同样的 groth16.Setup 生成的。这不影响耗时，因为证明时间取决于电路结构，与密钥的具体数值无关。仓库 README 也写明，仓库里那套密钥本身就是单方 Setup 生成的开发测试产物，并非多方可信设置仪式的结果，生产部署需要另做仪式，这和博客说 Groth16 需要可信设置是一致的。
测试环境是一台单核 Linux 虚拟机，Intel Xeon 2.1GHz，3GB 内存。每档连续生成 20 个证明，整套测试隔几分钟后又完整跑了第二轮。
测出来的数
第二轮的结果：k=6 的证明，20 次中位数 1.96 秒，最快 1.94 秒，最慢 2.12 秒；k=2 的中位数是 0.96 秒。第一轮分别是 1.97 秒和 0.96 秒，两轮相差不到 1%。验证一个证明只要 1.9 毫秒。
这组数字落在博客给的区间里。更值得看的是生成和验证的比例，1.96 秒对 1.9 毫秒，大约 1,000 比 1。博客说时间主要花在生成上、验证很便宜，这个比例把「主要」两个字变成了一个具体的倍数。
我还做了一个反向检查。测试集里附带两组故意改错的数据：k=2 那组把一个转账金额从 0 改成了 10，k=6 那组篡改了一个哈希值。两组都在证明阶段被拒绝，分别报第 517 条和第 1085 条约束不满足，生成不出证明。这当然不能说明电路没有漏洞，只说明这两种明显的篡改会被挡住。
两个博客里没有的细节
第一个细节在电路规模上。每多一个参与方，约束数固定增加 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 字节，是前面每档的三倍多。耗时的方向也对得上：约束从 k=2 到 k=6 多了 87%，证明时间多了 104%。跨过边界这一步单独多花了多少时间，要等有 k=3 到 k=5 的交易数据才能拆开，仓库目前只提供了 k=2 和 k=6 两档，所以现在能确认的是方向一致。如果生产环境用的就是 k=6，那它正好坐在这道边界的另一侧，从 k=5 换到 k=6 的代价会比前面几档之间大，这是我的推断，不是博客的说法。
第二个细节是一致性。我从公开源码生成的五档证明密钥，文件大小和仓库记录的官方构建产物精确到字节完全相同，k=6 的验证密钥也一样。密钥内容必然不同，因为每次 Setup 都会重新随机生成，但大小完全一致，说明公开源码编译出的电路结构和官方构建是同一套。上一篇写 Axyl 审计时我提过，公开仓库和审计时的私有版本之间有一段追溯不了的历史。这次在证明服务这边，至少源码和官方构建这一段对上了；官方构建和生产部署是否一致，公开材料还回答不了。
把博客的问题代进真实负载
先接上上一篇。那篇我拆过 15,000+ TPS 几个数字的出处，它们描述的是 Axyl 共识层。这次测的是另一层，也就是每笔机密交易在发送方那里要先花掉的证明时间。两层的数字不能相加，也不能互相替代。
博客举的量级是：大型代理行关系每天几千笔，一个央行级的代币化实时全额结算服务每天几万笔大额转账。我换成两个现成系统的公开数据。美联储 Fedwire 资金服务 2025 年日均 869,187 笔，英国 CHAPS 2025 全年日均 210,483 笔，分别是博客举例的几十倍和几倍。
下面是我算的，不是博客的说法。按单核实测的 1.96 秒一个 k=6 证明，一个核一天最多生成约 44,000 个。把 Fedwire 2025 年的日均笔数全部换成 k=6 证明，需要约 473 个核小时，相当于 20 个核全天不停；CHAPS 需要约 115 个核小时，不到 5 个核。英格兰银行 2021 年的介绍材料记载，CHAPS 单日笔数纪录是 2018 年 3 月 29 日的 320,034 笔，约为当年日均的 1.7 倍，按这个峰值算也只要约 174 个核小时。
这个推算的口径要说清楚。它按每个证明占用一个核来折算，证明之间彼此独立，可以分到不同的核上同时生成。它算的是转账证明本身，存入、提取和 DvP 属于另外的电路，网络传输和上链结算也不在其中。另外，博客说证明由发送方生成，也就是负载天然分散在各家机构自己的节点上，并不集中在一台机器上。
所以我的结论是：博客说银行间结算量在机密结算系统的能力范围内，这个判断在真实量级下依然成立。它自己举的量比现实系统小，把真实数字代进去结论照样站得住，这反而比原文的举例更有说服力。零售支付那一段，博客自己承认那是真正的瓶颈，这次的数字不改变那个判断。
这组数字该怎么用
这次的数字全部来自单核，可以当作一个偏保守的参考。原因在代码里：gnark 生成证明时，最重的多标量乘法会按机器的 CPU 核数拆成多个任务同时计算（backend/groth16/bn254/prove.go 里直接读取 runtime.NumCPU()）。机构服务器通常是多核，同一个证明会被分给更多核一起算，耗时会低于这里的单核结果，具体能快多少取决于核数和单核性能。
本文的测量范围是转账电路的证明生成本身。完整的 HTTP 服务链路里还有 JSON 解析和网络开销，存入、提取和 DvP 则是另外几类电路。密钥大小一致说明电路结构相同，但不代表密钥内容相同，这一点前面已经解释过。
我的看法
博客的标题是 honest math，正文给出的数字却只有一个区间。这次跑下来，区间是对的，银行间结算那部分的结论也站得住。
我更想看到的是下一步。Axyl 的基准页写明了四节点委员会和 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 年版）。