前两篇我在一台云服务器上测了 Rayls 的证明代码，但数字只来自一种机器，测试代码也没放在读者能直接复现的地方。这次我把测试代码公开到 GitHub，让 GitHub 自己的服务器替我跑，换了三种 CPU，日志谁都能点开看。
先给短答案。以 Rayls Enygma 隐私转账电路的 6 人匿名集为例，一笔转账的零知识证明只用 1 个 vCPU 时要 1.55 到 1.95 秒，在 4 个 vCPU 上要 0.63 到 0.71 秒，验证这个证明只要 1 毫秒左右。服务第一次处理某一档转账时，还要额外花 1.9 到 2.9 秒把证明密钥读进内存。按串行处理请求算，一台 4 vCPU 的云服务器每秒能出 1.4 到 1.6 个证明。
下面讲这些数字是怎么来的、在哪里能复现，以及它们对一家机构要准备多少机器意味着什么。
隐私转账为什么要"算"
零知识证明可以理解成一张数学凭证：付款方不公开余额、金额和对手方，也能向网络证明这笔账是对的。代价在生成这张凭证上。Rayls 的 Enygma 用的是 Groth16 证明系统，它的特点是证明很小、验证很快，生成却要做大量椭圆曲线运算。所以"隐私要多少算力"这个问题，实际问的是生成证明要多久。
这里的 k 是匿名集大小。一笔转账会给 k 个参与方各生成一个金额承诺，真正的收款方藏在其中，旁人看不出是谁付给了谁。k 越大藏得越深，电路也越大。Rayls 仓库自带的压力测试脚本用的是 k=6，所以下文主要看 k=6。
这些结论不只适用于 Rayls。凡是用 Groth16 做隐私转账的系统，成本都落在同样的环节上，只是电路规模不同。
怎么测的，任何人都能复现
被测的是 Rayls 开源的证明服务 rayls-sovereign-gnark-api，提交 67c4c26。电路和证明代码一行没改。我的测试代码放在公开仓库 hansonhan0520-lang/enygma-bench，脚本会自动拉取这个提交，把测试文件放进它的电路目录，调用仓库自己的证明函数。
测试代码放进仓库后，由 GitHub 自己的云服务器（GitHub Actions）运行。每次运行的完整日志都自动提交到仓库的 results 文件夹，读者点 Actions 页面的 Run workflow 就能在自己的账号下再跑一遍。GitHub 文档写明，公开仓库的标准 Linux 运行器是 4 个 CPU、16 GB 内存，分 x64 和 arm64 两种。
本文用到三台机器，每台的 CPU 拓扑都由日志里的 lscpu 记录：
GitHub x64 运行器，Intel Xeon Platinum 8573C，4 个 vCPU，实为 2 个物理核、每核 2 个线程。
GitHub arm64 运行器，ARM Neoverse-N2，4 个 vCPU，4 个物理核、每核 1 个线程。
我自己的云端环境，Intel Xeon 2.1GHz，2 个物理核。
每台机器上，k=2 到 6 每一档先生成一个证明并用验证密钥验过，再连续计时 20 次取中位数，分别把可用的 vCPU 限定为 1 个、2 个、4 个各测一遍，我那台只有 2 个。GitHub 两台的数字来自 Actions 运行 37741247183，第三台来自同一天的本地运行，全文的数字和两张图都从同一份数据文件生成。
哪些是新的，这里说清楚。k=3 到 5 的测试数据沿用我上一篇写的生成器，它先逐字段复现了 Rayls 官方发布的 k=2 和 k=6 两组数据才被采用，这次没有改。这篇新增的是：公开可复现的测试仓库，两种新 CPU 上的 4 vCPU 测量，以及密钥加载时间的单独计时。
换 CPU 差多少
k=6 只用 1 个 vCPU 时的证明时间，Intel 8573C 是 1.55 秒，Neoverse-N2 是 1.81 秒，我那台 2.1GHz Xeon 是 1.95 秒，最慢的比最快的多 26%。用满全部 vCPU 后，两台 GitHub 机器分别是 0.71 秒和 0.63 秒，我那台用满 2 个 vCPU 是 1.37 秒。
验证时间在三台机器上都在 1 毫秒左右，从 0.98 到 1.28 毫秒。证明本身固定 164 字节，随证明一起传递的公开数据在 k=6 时是 1,612 字节，三台机器完全一致。
多核能快多少，取决于是不是真的核
这是这次最意外的结果。从 1 个 vCPU 到 2 个，两台 GitHub 机器都快了 1.88 到 1.89 倍，接近翻倍。但从 2 个到 4 个，两台分道扬镳：Neoverse-N2 又快了 1.51 倍，Intel 8573C 只快了 1.17 倍。
两台机器的差别在 lscpu 里写得很清楚。Neoverse-N2 的 4 个 vCPU 是 4 个物理核，Intel 8573C 的 4 个 vCPU 是 2 个物理核各跑 2 个线程。所以在 Intel 这台上，"从 2 个 vCPU 到 4 个"其实没有增加物理核，只是让每个核多跑一个线程。加速比和物理核数对得上，这是我从拓扑记录推出的解释，不同 CPU 的缓存和频率差异没有单独拆开。
同一个 x64 运行器标签，两次运行分到的硬件也不一样。同一天早些时候的一次运行分到的是 AMD EPYC 9V45，从 2 个 vCPU 到 4 个同样只快了 1.18 倍，但那次没记录拓扑，所以我不把它算作证据。读者自己复现时，x64 那台可能分到别的 CPU，看日志开头的 lscpu 就知道是哪种。
这条也修正了我自己。上一篇在我的云端环境测到 2 个 vCPU 平均只快 1.64 倍，当时没有说明这可能只是那台机器的情况。这次同一环境下 k=6 只快 1.43 倍，而两台 GitHub 机器接近 1.9 倍。所以"翻倍资源快不到两倍"更像是那台云端机器的特点，在另外两种 CPU 上并不成立。
第 6 个参与者的台阶，换了 CPU 还在
上一篇在单台机器上测到，k=5 到 k=6 这一步比前面每一步贵得多。这次三台机器都复现了。只用 1 个 vCPU 时，k=2 到 5 之间每加一个参与者平均多花 114 到 143 毫秒，而 k=5 到 6 这一步要多花 451 到 619 毫秒，是前面平均值的 3.5 到 5.0 倍。
原因和上一篇一样：约束数每多一个参与者固定增加 8,112 条，但证明系统按 2 的幂次分配计算空间，k=2 到 5 都在 65,536 以内，k=6 越过了这条线，计算空间变成 131,072。三台机器、两种指令集上，这个计算空间的数值完全相同，这次多出来的信息是：台阶出在电路本身，和 CPU 无关。
冷启动慢在哪
上一篇我测到服务第一次处理某一档请求要多花 2.5 到 4.5 秒，并把原因归到加载证明密钥上，但没有单独测量。评审指出了这一点。
这次我单独计时了服务首次请求时调用的两个加载函数，一个读约束系统，一个读证明密钥，和服务代码 handler.go 里用的是同一组函数。k=6 时，读证明密钥在三台机器上要 1.94 到 2.94 秒，读约束系统只要 0.05 到 0.08 秒。
把加载时间加上一次热请求的耗时，和实测的冷请求相比，两台 GitHub 机器相差 22 毫秒和 12 毫秒，我那台相差 0.2 秒。所以冷启动基本就是读证明密钥的时间。对部署的意义很直接：服务启动时预先加载五档密钥，或者先发一轮预热请求，第一笔真实交易就不会多等这 2 到 3 秒。
一家机构要准备几台机器
这一节是推算，不是测量。按串行处理请求，一台 4 vCPU 机器在 k=6 下每秒能出 1.41 个（Intel 8573C）到 1.58 个（Neoverse-N2）证明。
英国 CHAPS 在 2025 财年平均每天处理 210,483 笔，结算时间是每个工作日 06:00 到 18:00，摊到 12 小时里约每秒 4.87 笔，需要 3.1 到 3.4 台这样的机器。英格兰银行 2021 年 12 月的 RTGS 与 CHAPS 介绍里记载的单日纪录，是 2018 年 3 月 29 日的 320,034 笔，按同样窗口约每秒 7.41 笔，需要 4.7 到 5.3 台。美国 Fedwire 2025 年平均每天 869,187 笔，按每天 22 小时的运行时间约每秒 10.97 笔，需要 6.9 到 7.8 台。
这些数字只是证明生成算力的一阶估算，不是 Rayls 的结算吞吐量。它们没有计入日内高峰、网络和账本的开销，也没有测试同一台机器上多个证明并行跑的情况。另外，证明由发起转账的机构各自生成，负载分散在各家机构，而不是集中在一台服务器上。
还没定的部分
这次只测了转账电路，存款、取款和 DvP 电路没有测。密钥是用仓库自己的 groth16.Setup 在本地生成的，Rayls 仓库的说明也写明，仓库里那套密钥同样是单方生成的开发测试产物，生产部署需要另做多方可信设置；证明时间取决于电路结构，和密钥的具体数值无关。Rayls 生产环境用的是什么硬件、匿名集大小设为多少，公开资料里我没有找到，所以上面的机器数只能说明量级。
我的看法
一笔零知识隐私转账的算力账，量级其实不大：1 个 vCPU 两秒以内，4 个 vCPU 不到一秒，验证的开销几乎可以忽略。真正要留意的有两处。一是匿名集大小越过 2 的幂次那一档时，成本会突然跳一截。二是第一次请求要先读两三秒的密钥。
判断标准也很简单：任何人都可以打开 enygma-bench 仓库的 Actions 页面再跑一遍，看自己拿到的 CPU 上数字是否落在同样的范围。如果 Rayls 将来公布生产环境的证明硬件，就可以直接拿这套测试去对照。
参考来源：
Rayls 证明服务源码，raylsnetwork/rayls-sovereign-gnark-api，提交 67c4c26（2026 年 8 月 20 日）：https://github.com/raylsnetwork/rayls-sovereign-gnark-api/commit/67c4c26696016b48e70950e284ae1a51b7d0cf0e
本文测试代码与全部日志，Actions 运行 37741247183（2026 年 10 月 8 日）：https://github.com/hansonhan0520-lang/enygma-bench
GitHub 托管运行器规格（2026 年 10 月 8 日查阅）：https://docs.github.com/en/actions/reference/runners/github-hosted-runners
Fedwire Funds 2025 年统计（页面更新于 2026 年 1 月 26 日）：https://www.frbservices.org/resources/financial-services/wires/volume-value-stats/annual-stats.html
英格兰银行支付与结算统计，CHAPS 2025 财年日均笔数：https://www.bankofengland.co.uk/payment-and-settlement/payment-and-settlement-statistics
英格兰银行《RTGS 与 CHAPS 简介》（2021 年 12 月），CHAPS 单日纪录：https://www.bankofengland.co.uk/-/media/boe/files/payments/rtgs-chaps-brief-intro.pdf
