在这项工作中，我们开始在a16z先前工作的基础上发布一个通用而公平的zkVM基准测试框架，比较ZKM（zkMIPs）与其他zkVM项目（例如RISC Zero（R0）和SP1）之间的时间和能源成本。
这份初始出版物侧重于将验证时间与R0进行比较，结果显示zkMIPS的性能在76％至317％之间接近，我们还提供了有关慢速案例和即将进行的优化的分析。
我们的目标是让 zkMips 成为市场上最适合量产的 zkVM 之一，也是利用 MIPS 指令集性能最高的 zkVM。
我们试图调查以下问题：
注意: 通过展示具体的实例类型和基准，我们实现了 zkvm-benchmark (https://github.com/zkMIPS/zkvm-benchmarks) 基于 a16z/zkvm-benchmark，将 R0 更新到最新的 v1.0.5，以确保结果直接可比且公平。
对于纯 CPU 机器，zkVM 仍然可以使用英特尔的 AVX 指令集来加快 Goldilocks 的操作。根据我们之前的经验，此功能可以帮助实现 6-10% 的加速。zkVM 在基准测试期间通过添加运行时标志启用了此功能 RUSTFLAGS=”-C target-cpu=native”。
所有基准测试都可以在以下网址找到 https://github.com/zkMIPS/zkvm-benchmarks
bef9edd。（https://github.com/zkMIPS/zkm/tree/main/prover/examples/revme )
CPU 实例：AWS r6a.8xlarge、32 个 vCPU 和 256G 内存、AMD EPYC 7R13 处理器
GPU 实例：64-vCPU、480G 内存、AMD EPYC 9354 32 核处理器、NV GeForce RTX 4090X4
zkMips 的分段大小为 262144 (2^21)。
通过对比，我们可以看出，在性能和能源成本方面，zkMIPS 与其他顶级 zkVM 相比具有竞争力。
此外，对我们在证明生成过程中的时间分布的分析如图 1 所示：
观察不同的分段，我们发现生成跟踪大约占总时间的10％-22％，计算每个表的承诺占用25％-32％，但是CTL（交叉表查询，基于GKR优化的LogUP方案）时间可以忽略不计。
按照设计，跟踪的生成只能在单个 CPU 上运行，但是不同表（如 CPU、算术等）的承诺计算可以在多个 CPU 上并行执行，从现在起减少了 2/3 的时间使用量。
证明生成最多需要大约 45% 的时间。关于证明计算，我们在图 2 中提供了详细的饼图-内存操作和 cpu 操作占总时间的约 72.8%，它与跟踪表的大小相匹配。
对于每代 STARK 证明，时间使用分布如下面的表 4,5 和 6 所示。不难看出，“计算辅助多项式承诺” 和 “计算空缺证明” 是最耗时的计算。“计算辅助多项式承诺” 包括基于波塞冬的默克尔·哈希和用于根据系数多项式计算点值格式多项式的 FFT。而 “计算开口证明” 是通过多项式乘法和除法（反转）运算计算开口点上的最终多项式。
表 4：计算单个 STARK 证明所用时间
表 5：计算辅助多项式的计算用时量
表 6：计算开口证明的时间使用情况
与 ZKM 使用的 Plonky2（在 Plonky2 中 FFT 和 Poseidon 是在现场金发姑娘上进行的）不同，RISC0 和 SP1 使用的是更有效的哈希函数和更小的场域，这可以极大地缩短验证时间。我们已经实现了 GPU Plonky2 并实现了 3 的加速。同时，我们正在寻求就地整合 Plonky2 上更有效的哈希函数和较小的字段，预计这将减少大约一半的时间和成本。
通过计划中的优化，我们有信心可以显著提高 zkMIP 的性能，使其与其他领先的 zkVM 更具竞争力。
我们一直在努力使这些基准比较尽可能准确。如果发现任何差异，请通过 contact@zkm.io 联系我们，我们将进行必要的更正。
在这项工作中，我们开始在a16z先前工作的基础上发布一个通用而公平的zkVM基准测试框架，比较ZKM（zkMIPs）与其他zkVM项目（例如RISC Zero（R0）和SP1）之间的时间和能源成本。
这份初始出版物侧重于将验证时间与R0进行比较，结果显示zkMIPS的性能在76％至317％之间接近，我们还提供了有关慢速案例和即将进行的优化的分析。
我们的目标是让 zkMips 成为市场上最适合量产的 zkVM 之一，也是利用 MIPS 指令集性能最高的 zkVM。
我们试图调查以下问题：
注意: 通过展示具体的实例类型和基准，我们实现了 zkvm-benchmark (https://github.com/zkMIPS/zkvm-benchmarks) 基于 a16z/zkvm-benchmark，将 R0 更新到最新的 v1.0.5，以确保结果直接可比且公平。
对于纯 CPU 机器，zkVM 仍然可以使用英特尔的 AVX 指令集来加快 Goldilocks 的操作。根据我们之前的经验，此功能可以帮助实现 6-10% 的加速。zkVM 在基准测试期间通过添加运行时标志启用了此功能 RUSTFLAGS=”-C target-cpu=native”。
所有基准测试都可以在以下网址找到 https://github.com/zkMIPS/zkvm-benchmarks
bef9edd。（https://github.com/zkMIPS/zkm/tree/main/prover/examples/revme )
CPU 实例：AWS r6a.8xlarge、32 个 vCPU 和 256G 内存、AMD EPYC 7R13 处理器
GPU 实例：64-vCPU、480G 内存、AMD EPYC 9354 32 核处理器、NV GeForce RTX 4090X4
zkMips 的分段大小为 262144 (2^21)。
通过对比，我们可以看出，在性能和能源成本方面，zkMIPS 与其他顶级 zkVM 相比具有竞争力。
此外，对我们在证明生成过程中的时间分布的分析如图 1 所示：
观察不同的分段，我们发现生成跟踪大约占总时间的10％-22％，计算每个表的承诺占用25％-32％，但是CTL（交叉表查询，基于GKR优化的LogUP方案）时间可以忽略不计。
按照设计，跟踪的生成只能在单个 CPU 上运行，但是不同表（如 CPU、算术等）的承诺计算可以在多个 CPU 上并行执行，从现在起减少了 2/3 的时间使用量。
证明生成最多需要大约 45% 的时间。关于证明计算，我们在图 2 中提供了详细的饼图-内存操作和 cpu 操作占总时间的约 72.8%，它与跟踪表的大小相匹配。
对于每代 STARK 证明，时间使用分布如下面的表 4,5 和 6 所示。不难看出，“计算辅助多项式承诺” 和 “计算空缺证明” 是最耗时的计算。“计算辅助多项式承诺” 包括基于波塞冬的默克尔·哈希和用于根据系数多项式计算点值格式多项式的 FFT。而 “计算开口证明” 是通过多项式乘法和除法（反转）运算计算开口点上的最终多项式。
表 4：计算单个 STARK 证明所用时间
表 5：计算辅助多项式的计算用时量
表 6：计算开口证明的时间使用情况
与 ZKM 使用的 Plonky2（在 Plonky2 中 FFT 和 Poseidon 是在现场金发姑娘上进行的）不同，RISC0 和 SP1 使用的是更有效的哈希函数和更小的场域，这可以极大地缩短验证时间。我们已经实现了 GPU Plonky2 并实现了 3 的加速。同时，我们正在寻求就地整合 Plonky2 上更有效的哈希函数和较小的字段，预计这将减少大约一半的时间和成本。
通过计划中的优化，我们有信心可以显著提高 zkMIP 的性能，使其与其他领先的 zkVM 更具竞争力。
我们一直在努力使这些基准比较尽可能准确。如果发现任何差异，请通过 contact@zkm.io 联系我们，我们将进行必要的更正。
