基于证明的通用计算：Magnetar 挑战 zkVM 的权衡
Microsoft Research 于 10 月 15 日推出了基于证明的通用计算系统 Magnetar，并称其速度最高可达同类零知识虚拟机的 39 倍。该系统能够证明使用常见编程语言编写的程序，同时隐藏私有输入。它还避免了竞争方案为换取性能而接受的若干密码学假设。
这一组合之所以重要，是因为证明系统通常迫使开发者在速度、通用性和保守安全性之间取舍。Magnetar 试图消除这种选择。Microsoft 表示，它可利用植根于标准哈希函数的安全性，以每秒数百万处理器周期的速度证明普通 RISC-V 程序。
其直接竞争对象并非某一家公司，而是 Jolt、SP1 及其他通用 zkVM 等系统背后既有的工程权衡。有些方案提供更短的证明、更成熟的开发者工具，或不同的性能特征。Magnetar 的主张是，开发者不再需要做出这些妥协，便可让可验证计算具备实用性。
基于证明的通用计算：Magnetar 改写性能论点
Magnetar 的重要性在于，它在一个研究系统中结合了普通代码、高证明吞吐量和后量子安全性。
零知识虚拟机，即 zkVM，可在无需验证者重新执行程序的情况下，证明程序被正确执行。启用零知识后，证明还可隐藏私有输入。这样一来，接收方能够获得结果的证据，而无需知晓其底层机密数据。
Microsoft 的 Magnetar research 将该系统定位为对三个相关问题的推进。证明生成必须足够快，以支持现实工作负载。开发者必须能够使用普通程序，而非手工构建的密码学电路。底层安全性则必须在系统预期生命周期内保持可信。
Magnetar 面向编译为 RV64I 的程序，即 RISC-V 基础 64 位整数指令集。RISC-V 为该系统提供了传统的处理器模型，以及成熟的编译器基础设施。开发者可以用 Rust、Go 或 C 编写软件，进行编译后，再为生成的执行过程提供证明。
这不同于要求将应用改写为算术电路的证明系统。电路通过证明系统可处理的代数约束描述计算。构建电路往往需要专业知识，而应用逻辑的改动也可能需要相应的电路工作。
zkVM 将大量这类负担转移至虚拟处理器中。证明系统验证处理器逐条指令的行为，因此程序可沿用标准编译路径。开发者仍需完成集成工作，但无需将每个应用表示为定制电路。
Microsoft 报告称，Magnetar 在一台 M4 Max MacBook Pro 上每秒可证明 720 万至 870 万个周期。所引实验使用了 12 个性能核心，执行过程包含 2²² 个周期。证明大小约为 600 KiB，验证耗时介于 11 至 13 毫秒之间。
据称，经优化的配置可达到每秒 950 万至 1280 万个周期。Microsoft 表示，这一改进使其测得的相对速度提升约 1.3 倍。这些是研究基准，而非生产服务测量结果。
配套的 technical paper 在 15 项工作负载中将 Magnetar 与 SP1 Hypercube、Jolt-Dory 和 Jolt-Akita 进行了比较。测试集包括密码学哈希、Merkle 树操作、签名，以及在一个小型 Ethereum Virtual Machine 解释器内进行的代币转移。
根据这些结果，Magnetar 相比 SP1 Hypercube 实现了约 39 倍的几何平均吞吐量优势。报告显示，其相对 Jolt-Dory 和 Jolt-Akita 的平均优势分别约为 18 倍和 9.6 倍。不同工作负载下的个别比较结果差异很大。
这些数据解释了为何这项发布比又一次渐进式零知识基准测试更具影响力。Magnetar 不只是声称在狭窄的定制电路中实现了更快执行。它宣称，一个通用、基于哈希的系统能够超越围绕较不保守密码学组件构建的替代方案。
这一性能论点仍有边界。基准测试由 Magnetar 的创建者在一种笔记本电脑配置上完成。生产环境会引入不同的内存限制、并发模式、网络成本和应用规模。独立复现将决定其领先优势能否在这些条件下延续。
不过，报告结果改变了举证责任。基于哈希的系统常被视为保守但昂贵。Magnetar 表示，保守的基础与有竞争力的证明速度可以并存。
标准语言让证明更接近日常软件
实际转变不仅是密码学速度更快，更在于形成了一条从持续维护的应用代码到可验证执行的路径。
理解 Magnetar zkVM 最简单的方式，是跟随一个程序在其中的运行过程。开发者使用受支持的语言编写应用，并将该应用编译为 RISC-V。随后，Magnetar 会生成证据，证明由此产生的处理器执行遵循了指定程序。
验证者无需重复执行每一条指令。它只需检查一份代表执行正确性的紧凑证明。Microsoft 表示，在其基准配置中，无论证明所代表的工作负载规模大得多，验证耗时约为 12 毫秒。
这改变了谁能够构建由证明支撑的应用。定制电路会将知识集中在同时理解应用与证明系统的团队手中。通用 zkVM 则让传统软件工程师能够保留更多既有的语言、编译器、测试和代码审查实践。
这一差异对于频繁变化的软件尤其重要。业务政策、数据管道、解释器和代理规则会随时间演变。为每次改动重建定制电路，可能会让密码学保证成为开发瓶颈。
Magnetar 并未让证明工程彻底消失。团队仍须选择要证明哪些陈述、定义公开和私有输入，并运行证明基础设施。他们还必须验证编译后的行为与预期的高层政策相符。
该系统改变的，是专业化的边界。密码学家可以专注于 zkVM 及其证明引擎，而应用开发者则面向熟悉的处理器架构。这种分工类似于编译器工程师与应用程序员之间的关系。
Microsoft 将 Ethereum Virtual Machine 解释器作为一个示例。用 Rust 或 Go 编写的 EVM 实现可在 Magnetar 内运行。由此形成的构造能够证明现有智能合约的执行，无需将每份合约直接实现为新的证明电路。
这一方法的相关性不止于区块链。金融机构可以证明交易处理程序执行了指定规则，而无需披露每笔交易。数据服务可以证明其对私有记录应用了约定的转换。
AI 代理则是另一种潜在用途。代理可以提供证据，表明某项操作经过了定义明确的政策程序。该证明能够确认该政策被执行，但不会自动说明该政策是否完整或合理。
这一限制至关重要。证明确认的是被精确编码的陈述。它不能证明源数据准确、政策覆盖了全部风险，或周边系统未遭入侵。
因此，基于证明的计算是审计、访问控制和运营安全的补充，而非替代。它的具体贡献在于：对于输入和程序已被妥善定义的计算，减少所需信任。
“Magnetar zkVM explained”这一说法听起来可能像产品教程，但重要新闻在于其架构。Microsoft 的论点是，可验证执行应成为普通软件的一种由编译器支撑的属性，而非独立的应用类别。
这一雄心给每个通用 zkVM 项目带来压力。如果证明仍然昂贵，仅有良好的开发者体验已不足够。如果原始速度依赖于买家预计未来会替换的假设，那么速度本身也同样不够。
Magnetar 与 Jolt 揭示真正的密码学权衡
核心竞争不只是 Magnetar 与 Jolt 的速度之争，更是标准哈希与更短证明、替代性假设之间的竞争。
Jolt 是一个有价值的比较对象，因为这两个项目拥有共同的思想和架构根源。两者都使用 RISC-V 支持通用程序，也都建立在让处理器指令和内存操作更易于证明的研究基础之上。
Jolt 使用查找论证，使证明系统能够确认数值属于预定义表。这比通过大量低层约束表达每条指令，更高效地表示处理器指令。
开源的 Jolt repository 将该项目描述为可扩展的 RISC-V zkVM。它也将当前软件标注为 alpha 阶段，不适合用于生产。这一警告说明了有前景的证明研究与可靠基础设施之间更广泛的差距。
Microsoft 评估了两种 Jolt 配置。Jolt-Dory 使用椭圆曲线假设，而 Jolt-Akita 使用基于格的密码学。Magnetar 的论文报告称，两者生成的证明均小于 100 KiB，而 Magnetar 的证明约为 600 KiB。
更小的证明可降低存储和传输成本。当证明需要跨越受限网络传输，或大量累积时，这一优势尤为重要。证明大小也会影响系统如何跨层组合验证。
Magnetar 接受更大的证明，以换取更为狭窄的安全基础。Microsoft 表示，其安全性建立在 SHA-256 或 SHA-3 等标准哈希函数之上。它不依赖椭圆曲线、格假设、专用代数哈希或可信设置。
可信设置是某些证明系统中用于创建秘密参数的一次性过程。如果这些秘密材料被保留或泄露，攻击者可能伪造证明。透明系统避免了这一仪式及其相关的治理负担。
椭圆曲线系统能够提供紧凑的证明和高效验证，但足够强大的量子计算机将威胁其安全性。基于格的系统旨在抵御已知量子攻击，尽管它们依赖不同的数学假设。
Magnetar 的立场更为保守。标准哈希函数已历经数十年的分析和部署。它们也广泛存在于现有软件和硬件中，为实现者提供了成熟的优化路径。
这并不意味着哈希函数绝对可靠。Magnetar 仍依赖其安全属性以及实现的正确性。“后量子”意味着能够抵御目前已知的量子攻击，而非对未来所有发现提供永久保证。
尽管如此，基于哈希的设计仍获得了机构层面的支持。NIST 于 2024 年在 FIPS 205 中标准化了 SLH-DSA——一种源自 SPHINCS+ 的无状态哈希签名方案。该标准面向数字签名而非 zkVM，但它说明了为何组织将哈希视为保守的后量子基础。
SP1 Hypercube 则提供了另一种对照。Microsoft 的论文将其描述为“基于哈希及其他机制”，因为其核心机制包含了超出常规哈希安全性的假设。研究人员称，Magnetar 的实测证明约比 SP1 Hypercube 小 4.6 倍。
这一性能对比十分醒目，但不应被视为完整的产品排名。开发者工具、支持的指令、硬件加速、递归成本、运营可靠性和生态系统集成，都会影响部署选择。
因此，Magnetar 与 Jolt 的较量是两套安全与工程方案之间的竞争，而不是孤立基准列之间的比较。Jolt 配置提供了显著更小的证明；Magnetar 则宣称具备更高的实测吞吐量和更少的底层假设。
这一结果促使竞争者更清楚地解释其选择。如今，选择 zkVM 的团队有理由追问：证明者受哪些假设保护、这些假设能否轻易变更，以及哪些成本并未体现在标题吞吐量中。
BinarySpartan 将保守安全性转化为速度
Magnetar 的核心机制将二进制计算、标准哈希和递归验证统一起来，而不是将它们视为彼此独立的问题。
Magnetar 建立在 BinarySpartan 之上，这是一种将早期 Spartan 设计引入二元域的证明系统。二元域通过面向比特的算术表示数值，因此天然适合处理器逻辑和标准哈希函数。
2019 年推出的 Spartan 提供了无需可信设置的通用证明。它采用了求和检验协议，使验证者能够通过规模小得多的代数信息交互，验证大规模且结构化的计算。
后续项目针对不同的性能瓶颈进行了改进。Phalanx 利用了处理器执行中的重复结构。Brakedown 开发了快速的基于哈希的承诺方法。Lasso、Twist、Shout 及相关工作则降低了证明查找与内存操作的成本。
Magnetar 将这些研究路线结合起来，而非依赖某一项孤立的发明。其处理器描述受益于重复的指令周期结构；其内存检查则采用了专为在证明中高效读写而设计的技术。
BinarySpartan 还与源自 Brakedown 的承诺方案 Ligerito 配合使用。承诺允许证明者在不立即披露数据的情况下，对数据作出绑定。验证者随后可检查开放值是否与承诺值一致。
环切换则提供了另一项组件。它使系统能够高效地对比特向量作出承诺，同时在适合不同阶段的代数表示之间切换。这项技术有助于将处理器执行轨迹与证明系统的二元域算术连接起来。
这些组件之所以重要，是因为 zkVM 需要证明的并不只是算术指令。它还必须说明指令解码、寄存器、内存一致性、分支，以及连续机器状态之间的关系。
内存历来尤其昂贵。证明必须表明每次读取都返回了此前正确写入的值，同时又无需在验证者内部重演一套常规内存系统。高效的内存论证可压缩这项一致性检查。
Magnetar 还支持递归，即一份证明可以证明另一份证明的验证过程。这使长计算能够被拆分为可管理的片段，再组合起来。
递归证明系统有时会遭遇一种棘手的不匹配：验证使用的操作可能无法由证明者的虚拟机高效处理。于是，为验证者生成证明本身就可能成为主要成本。
Magnetar 尝试避免这种不匹配。其验证工作主要由标准哈希计算和二元域算术构成，而这些正是 BinarySpartan 被设计为能够高效证明的操作。
其结果是一种架构对齐。该系统证明普通的二进制处理器行为，使用标准哈希保障承诺，并且能够高效地证明自身验证者。每一层都强化了相同的计算模型。
Microsoft 表示，这一设计可通过证明各个片段并将其折叠组合，支持任意长度的计算。它还将长期运行的账本和区块链列为潜在目标。
任意长度并不意味着成本恒定。仍然必须有人执行计算并生成每个证明片段。递归改变了验证和聚合的扩展方式，但并未消除生成证明的工作。
这一机制也解释了所报告的速度。Magnetar 并非将后量子安全性附加到现有的曲线导向设计之上，而是从一开始就围绕对比特友好的操作来组织处理器、承诺、内存论证和递归。
这是将 Magnetar zkVM 作为工程故事来理解时最有力的部分。其速度与安全性主张源于同一项设计决策，而不是两项彼此无关的优化。
基准测试仍留下重要问题未解
Magnetar 改变了研究层面的比较格局，但尚未证明其已具备生产就绪性或普遍优越性。
首个不确定性涉及独立验证。现有性能数据来自 Microsoft Research 及其技术论文。外部团队需要在可比的硬件、软件版本和工作负载输入上复现这些结果。
基准测试的选择同样重要。15 个应用程序提供的证据多于单一合成测试，但它们并不代表所有生产工作负载。数据库密集型程序、大型解释器、异常内存模式和持续运行的多用户服务，都可能暴露不同的瓶颈。
周期吞吐量只是一个指标。团队同样关心峰值内存消耗、生成证明的延迟、启动成本、并行扩展、云端效率和故障恢复。这些因素可能主导已部署证明者的经济性。
600 KiB 的证明大小值得特别关注。它小于论文中与 SP1 Hypercube 的对比结果，但大于所报告的 Jolt 证明。需要发布或传输大量证明的应用必须直接评估这一差异。
对语言支持也需要谨慎解读。Rust、Go 和 C 可以编译至 RISC-V，但并非每一项语言特性、库、操作系统调用或运行时行为都会自动在 zkVM 内工作。熟悉的源语言并不等于不受限制的兼容性。
开发者需要有文档的工具链、调试器、性能分析支持、可复现构建和清晰的错误报告。成熟的编译器支持有所帮助，但 zkVM 仍定义了受约束的执行环境。
安全审查仍是另一项要求。Magnetar 在密码学假设层面可能只依赖标准哈希，但其实现仍包括处理器模型、证明代码、编译器、主机接口和应用逻辑。
这些组件中任一部分的缺陷都可能造成错误声明或可被利用的集成问题。保守的原语降低了一类风险，但并不会从部署计划中移除软件保障工作。
量子抗性主张也需要精确表述。Microsoft 表示，Magnetar 避开椭圆曲线，并依赖被认为可抵御已知量子攻击的哈希函数。量子算法仍可能影响哈希函数的有效安全级别，因此参数选择必须考虑这种降低。
Microsoft 将 Magnetar 置于更广泛的迁移工作之中。其 量子安全时间表 目标是在 2029 年前将产品和服务迁移至后量子密码学。Magnetar 与这一方向一致，但这项研究公告并不意味着它已成为部署中的 Microsoft 服务。
因此，商业可用性仍是一个重要的开放问题。公告描述了研究结果，并邀请组织讨论用例；但未提供生产发布日期、服务级别承诺或广泛部署路线图。
这些细节的缺失并不会削弱技术成果。它改变了买方应从中推断出的结论。Magnetar 目前确立的是新的研究基线，而非现有证明基础设施的交钥匙替代方案。
所有证明系统还共享一项语义局限。Magnetar 可以证明指定代码在已承诺输入上运行过，但无法判断代码是否代表正确的政策，也无法判断输入源是否如实提供信息。
以一个证明遵守审批规则的 AI agent 为例。该证明可以显示规则已执行，但无法显示被遗漏的规则本应阻止该操作，也无法显示外部数据源是否准确。
同样的问题也适用于金融。证明可以确立交易处理程序遵循了已编码的约束，同时不披露交易细节。监管机构和交易对手仍必须评估规则、输入来源、治理和例外情况。
这些限制应当塑造采用方式。基于证明的计算在声明、程序和输入承诺可被精确定义的场景中最为强大；当组织期待密码学解决模糊政策或不可靠数据时，其作用则较弱。
三个信号将表明 Magnetar 是否走出研究阶段
下一项考验在于，独立开发者能否复现 Magnetar 的收益，并将其转化为可持续的应用。
第一个信号是公开的实现证据。研究人员和开发者需要足够的代码、参数、基准输入和构建说明，以复现每秒 720 万至 870 万周期的范围。
在其他处理器上复现将增强 Microsoft 的性能论据。若结果随硬件或内存配置而剧烈变化，则会缩小这一论据的适用范围。比较还应采用等效的安全级别和工作负载定义。
这一细节之所以重要，是因为证明系统基准对实现选择异常敏感。某种配置可能以证明大小、内存、安全性或预处理为代价，换取更高吞吐量。看似可比的标签并不总意味着可比的保障。
第二个信号是由研究团队外部的团队维护的真实应用。可信的部署应使用普通的 Rust、Go 或 C 代码，并在现实的运营约束下生成证明。
EVM 解释器是一个可能的测试。受监管的数据处理工作流或 agent 政策引擎也同样具有参考价值。最有力的案例将公布延迟、内存使用、证明大小和运营故障数据。
此类部署将检验这样一种主张：使用 Magnetar 的基于证明的通用计算能够减少专门开发工作。编译器兼容性、调试和更新流程与基准吞吐量同样重要。
第三个信号是竞争 zkVM 项目的回应。Jolt、SP1、RISC Zero 和其他团队可以通过新的基准测试、更小的证明、硬件加速或替代性安全分析来挑战 Microsoft 的结果。
如果回应只聚焦于每秒最大周期数，反而会强化 Magnetar 的叙事。若回应能展示更低的总成本或更高的生产可靠性，则可能削弱这一叙事。市场需要覆盖整个证明流程的对比。
竞争对手也可能采用更保守的组件。如果标准哈希安全性成为采购要求，项目将需要提供兼容模式，或说明为何其假设能够提供可接受的替代方案。
因此，即使 Microsoft 的工作未成为主导性实现，也可能影响 zkVM 的设计。它提高了同时解释安全假设、编程兼容性和递归成本的基准预期。
开发者应关注可用版本、独立的基准测试套件，以及能够证明不止加密货币交易的应用。这些进展将表明，该架构能否超越经过严格控制的研究工作负载，实现更广泛的适用性。
企业买家则应提出另一组问题。证明究竟确立了什么陈述？哪些输入仍保持私密？哪些假设保护该证明？如果这些假设发生变化，系统将如何应对？
评估这项技术的团队还需要保存一份经得起长期检验的基准条件与安全决策记录。可搜索的工程知识库能够关联论文、测试结果、实施说明和审查发现，而不会将决策简化为单一的标题数字。
采用 Magnetar 的基于证明的通用计算，已经挑战了一项熟悉的假设：保守的后量子安全性并不一定意味着缓慢、专用的程序。下一步是对 Magnetar 本身进行验证。独立团队能否复现这些数据、维护普通应用程序，并在生产压力下保持其所宣称的安全性？
