递归 ZK 证明

什么是递归 ZK 证明？

递归 ZK 证明是用于验证其他零知识证明的零知识证明。

在加密领域，这意味着一个证明可以证明另一个证明有效，而该证明又可以被纳入另一个证明中。

由此形成一条证明验证链，许多计算、交易或状态更新都可以压缩为一个更小的最终证明。

普通零知识证明允许证明者在不披露陈述背后全部隐私信息的情况下，证明该陈述为真。

Ethereum 零知识证明文档指出，零知识证明允许证明者在不透露声明内容本身的情况下证明其有效性。

递归 ZK 证明更进一步，它证明先前的证明是正确生成的。

因此，递归证明常被称为“证明的证明”。

区块链无需在链上验证数千个独立证明，而是可以验证一个代表所有这些证明的最终递归证明。

这使递归 ZK 证明成为区块链扩容、Rollup、隐私系统、轻客户端、证明聚合和可验证计算的重要技术。

递归的核心价值在于，在保证密码学完整性的同时实现压缩。

即使最终证明代表了大量工作，其体积仍可以保持较小。

递归 ZK 证明为何对加密领域至关重要

递归 ZK 证明之所以重要，是因为区块链的空间、计算能力和链上验证能力都有限。

如果每笔交易、每次状态转换或每个证明都必须在基础层单独验证，成本可能会高到用户和开发者难以承受。

递归证明可以将许多已验证的工作合并为一个紧凑对象，从而减轻这一负担。

这对 ZK-rollup 尤其有用。ZK-rollup 在链下处理交易，并向基础链提交有效性证明。

Ethereum ZK-rollup 文档将 ZK-rollup 描述为一种扩容方案：将计算和状态存储移至链下，同时向 Ethereum 提交有效性证明。

递归证明可以让这种模式更高效，因为多个交易证明或批次证明可以在最终结算前聚合。

这可能降低验证成本、提高吞吐量，并减少基础链需要直接处理的证明数据量。

递归证明对用户也很重要，因为它们可以让区块链系统更快、成本更低，同时不要求用户信任中心化运营方。

如果设计得当，系统安全性来自密码学验证，而不是对服务提供商的盲目信任。

因此，递归 ZK 证明是构建可扩展且最大限度减少信任依赖的加密基础设施的重要组件。

递归 ZK 证明如何运作

递归 ZK 证明通过将一个证明系统的验证器放入另一个证明电路中来实现。

简单来说，新证明会检查旧证明是否有效。

证明者证明的不只是某笔交易或某项计算本身。

证明者还会证明，先前的证明已成功验证了更早的计算。

这一过程可以重复多次。

例如，证明 A 验证一组交易。

证明 B 验证证明 A 和另一组交易。

证明 C 验证证明 B 及更多交易数据。

最后，验证者只需检查证明 C，就能确信其背后整条工作链的有效性。

这并不意味着旧数据会以某种神奇方式消失。

它意味着旧计算的正确性由一个紧凑的密码学证明来表示。

要确保系统安全，仍然需要适当的数据可用性、健全的证明构造、安全的电路和可靠的假设。

递归 ZK 证明的强大之处在于，它将重复验证转化为可扩展的证明组合过程。

递归证明与证明聚合

证明聚合是将多个证明合并为一个证明。

递归 ZK 证明是实现证明聚合的一种常见方式。

系统无需让基础链验证数百个独立的有效性证明，而是可以递归合并这些证明，再提交一个最终证明。

这很有用，因为链上验证证明需要花费资金并占用区块空间。

如果区块链可以验证一个聚合证明，而不是多个独立证明，总成本可能会更低。

聚合还有助于缩短延迟并优化系统设计。

不同的证明者可以并行生成不同交易批次的证明。

随后，这些证明可以逐步合并为一个最终证明。

Starknet SHARP 文档指出，递归证明可以支持并行处理、降低用户延迟和链上成本，并提高证明效率。

这就是递归证明聚合对高吞吐量加密系统至关重要的原因。

它可以将许多小型证明任务转化为一个最终验证任务。

递归 ZK 证明与 ZK-rollup

ZK-rollup 是递归 ZK 证明最重要的加密应用场景之一。

ZK-rollup 在基础链之外处理大量交易，并提交有效性证明，以证明这些交易已被正确处理。

如果没有递归，Rollup 可能需要为不同批次生成并验证大型证明或多个独立证明。

借助递归，Rollup 可以先证明一个批次，再证明另一个批次，然后将这些证明合并为一个更大的证明。

这样，Rollup 就可以扩展证明生成能力，同时保持最终验证步骤精简。

递归证明还可以帮助 Rollup 安排证明者的工作负载。

一个证明者可以处理一小组交易，另一个证明者则处理不同的一组交易。

之后，系统可以递归合并这些结果。

这有助于提高证明过程的并行性，使其更适用于大规模交易。

最终证明可以提交至基础链，由智能合约验证 Rollup 的状态转换是否有效。

对用户而言，这有助于降低手续费、加快结算，同时保留强有力的密码学保障。

递归 ZK 证明与简洁型区块链

递归 ZK 证明还可以帮助构建简洁型区块链。

简洁型区块链的设计目标是让用户无需下载并验证完整的链上历史记录，就能检查当前状态。

用户可以改为验证一个代表区块链历史有效性的紧凑证明。

Mina Protocol 文档指出，Mina 使用递归零知识证明，使参与者可以通过一个小型证明来验证网络和交易，而不必从头验证整条区块链。

Mina SNARK worker 文档还指出，递归证明有助于将区块链压缩至固定大小。

这与传统区块链的模式不同：传统区块链的新用户可能需要下载大量历史数据，才能独立验证网络。

递归证明可以让验证更轻量、更易于使用。

这有助于硬件配置有限、使用移动设备或网络带宽较低的用户更直接地参与验证。

其目标不只是节省存储空间。

更深层的目标是在不牺牲密码学可信度的前提下，降低区块链验证成本。

递归 ZK 证明与隐私

递归 ZK 证明可以支持注重隐私的加密系统，让用户在不暴露数据本身的情况下证明与隐私数据相关的陈述。

例如，用户可以证明某笔隐私交易有效，而不透露发送方、接收方、金额或完整交易路径。

随后，递归可以将多个隐私证明合并为一个更大的证明，以验证整个系统状态。

这很有用，因为隐私系统通常既需要保密性，也需要可扩展性。

如果没有证明聚合，验证许多隐私交易的成本可能会很高。

借助递归证明，多个隐私操作可以打包到一个最终证明中。

这有助于在保护用户数据的同时减少链上验证工作。

注重隐私的 Rollup、隐私智能合约系统和身份应用都可以从这种模式中受益。

不过，隐私保障并非仅靠递归即可实现。

电路必须经过正确设计，必须控制元数据泄露，用户也必须了解哪些信息仍然公开。

递归证明可以隐藏某些隐私输入，但不会自动隐藏所有钱包行为模式、时间信号或应用层行为。

递归 ZK 证明与可验证计算

递归 ZK 证明也适用于可验证计算。

可验证计算是指一方执行计算，另一方可以高效验证该计算是否正确完成。

在加密领域，这可以应用于机器学习输出、游戏逻辑、身份验证、合规证明、拍卖、投票系统、预言机计算和链下执行。

直接在链上验证大型计算的成本可能过高。

递归证明可以将工作拆分为较小的部分，再逐步合并这些部分的证明。

Mina 递归教程指出，递归 ZKP 有助于构建原本难以实现的大型交易，并支持在链下由多方共同构建证明。

这很重要，因为许多加密应用希望将繁重的计算转移至链下，同时确保链上验证安全。

递归证明为开发者提供了一种证明复杂工作的方法，无需所有区块链节点重复执行这些工作。

这可以提高可扩展性，并让新的应用设计成为可能。

递归 ZK 证明与轻客户端

轻客户端是指无需运行完整节点即可验证区块链信息的用户或应用。

递归 ZK 证明可以为轻客户端提供更强的保障，因为它们能够提供证明链状态有效性的紧凑证据。

轻客户端无需信任服务器报告正确状态，而是可以验证一份关于状态转换历史的证明。

这有助于减少钱包、跨链桥、移动客户端和跨链应用的信任假设。

例如，跨链桥可能希望在不信任小型委员会的情况下验证另一条链的状态。

递归证明可以用另一条链能够验证的形式，表示多个区块或状态转换。

这并不能消除所有跨链桥风险。

证明系统、数据可用性、验证器合约、升级控制和链的相关假设仍然很重要。

不过，递归证明可以用数学验证取代部分对个人或机构的信任，从而减少对外部信任的依赖。

这也是递归证明研究对跨链基础设施十分重要的原因之一。

递归 ZK-SNARK

递归 ZK-SNARK 是基于 SNARK 证明系统构建的递归证明。

SNARK 是“简洁非交互式知识论证”（succinct non-interactive argument of knowledge）的缩写。

SNARK 的优势在于证明体积可能较小，且验证效率较高。

当系统需要持续验证先前的证明，同时保持最终证明紧凑时，递归 SNARK 就很有用。

Mina 是递归 SNARK 在加密领域最知名的应用案例之一。

Mina o1js 递归 ZK 证明文档将递归描述为一种利用 ZK 证明解决复杂问题的强大工具。

SNARK 递归在技术上颇具挑战，因为证明验证器必须能够高效地表示在另一个电路中。

这通常需要仔细选择椭圆曲线、算术化方案、证明系统、可信设置假设和电路设计。

如果设计得当，递归 SNARK 可以为区块链系统提供强大的压缩能力和高效验证。

递归 ZK-STARK

递归 ZK-STARK 是基于 STARK 证明系统构建的递归证明。

STARK 是“可扩展透明知识论证”（scalable transparent argument of knowledge）的缩写。

STARK 常因其透明性和可扩展性而受到关注。

在区块链系统中，递归 STARK 可以帮助聚合证明，并降低最终链上验证成本。

Starknet 的 SHARP 系统是基于 STARK 的生态中递归证明聚合的实际案例。

Starknet 文档指出，SHARP 会在将最终证明发送给链上验证器之前递归聚合证明。

当许多独立程序或批次需要得到证明并高效结算时，递归 STARK 系统可能非常有价值。

它们还可以支持共享证明基础设施，让不同应用从聚合验证中受益。

与 SNARK 一样，其安全性取决于实现是否正确、假设是否健全、验证器设计是否审慎，以及与结算层的集成是否安全。

递归证明与 Plonky2

Plonky2 是一种侧重于快速递归组合的证明系统。

Plonky2 论文将 Plonky2 描述为一种密码学论证实现，重点在于快速递归组合。

在加密领域，Plonky2 这类证明系统很重要，因为递归能力可能受到证明速度、验证成本和电路复杂性的限制。

如果递归速度太慢，证明聚合就可能难以应用于实际交易系统。

如果递归验证成本过高，最终证明带来的成本节省可能不足。

快速递归证明系统旨在让证明组合更适用于 Rollup、zkVM、跨链桥和其他区块链基础设施。

更广泛的启示是，递归 ZK 证明设计不仅关乎数学上的可行性。

它也关乎工程性能。

递归证明系统必须足够快速、体积足够小且足够可靠，才能用于生产级加密系统。

递归 ZK 证明与 zkVM

zkVM 是一种用于证明程序正确执行的零知识虚拟机。

递归 ZK 证明可以将大型程序的执行拆分为较小的片段，帮助 zkVM 系统为其生成证明。

每个片段都可以生成一个证明。

随后，这些证明可以递归合并为一个证明完整程序执行过程的最终证明。

这是因为一次性证明大型程序的成本可能很高，甚至难以实现。

递归让 zkVM 设计者可以横向扩展证明工作负载。

不同机器或证明者可以分别处理不同片段。

最终证明可以代表完整的执行轨迹。

这种模式对未来的区块链应用十分重要，因为这些应用希望证明复杂的链下计算，并以较低成本在链上验证。

它可以支持 Rollup 执行、协处理器、可证明游戏、隐私应用和可验证 AI 相关工作流。

递归 ZK 证明与普通 ZK 证明的区别

普通 ZK 证明用于证明关于数据或计算的陈述。

递归 ZK 证明则用于证明包含另一证明有效性在内的陈述。

这种差异会影响证明系统的扩展方式。

使用普通证明时，如果涉及许多计算，验证者可能需要检查多个独立证明。

使用递归证明时，可以合并这些证明，让验证者只检查一个最终证明。

普通证明仍然有用，而且通常更简单。

递归证明更复杂，但可以支持规模更大的系统。

开发者不应仅仅因为递归听起来先进就使用它。

当系统需要证明聚合、大规模计算、链历史压缩或多步骤验证时，递归最有用。

对于小型应用，普通证明可能更容易、更便宜，也更安全地实现。

递归 ZK 证明与批量验证的区别

递归证明聚合不同于简单的批量验证。

批量验证是指比逐一检查更高效地同时检查多个证明。

递归证明聚合则是创建一个新证明，用来证明先前的证明有效。

批量验证可以降低验证成本，但验证者仍可能需要处理多个证明对象。

递归聚合则可以将多个证明压缩为一个证明对象。

这一区别对区块链很重要，因为链上验证能力受到严格限制。

智能合约验证一个紧凑证明，可能比验证多个独立证明成本更低。

递归聚合还可以构建证明树，分阶段合并多个证明。

这种结构适用于并行证明和大型 Rollup 系统。

最佳设计取决于证明大小、证明成本、验证成本、延迟和结算要求。

递归 ZK 证明的优势

第一项主要优势是可扩展性。

递归证明可以将多个证明或计算压缩为一个最终证明。

第二项优势是降低验证成本。

区块链可能只需验证一个证明，而不是多个独立证明。

第三项优势是支持并行证明。

多个证明者可以处理工作负载的不同部分，之后再合并证明。

第四项优势是改进轻客户端验证。

用户可以验证紧凑证明，而不必检查大量历史记录。

第五项优势是支持更强的隐私系统设计。

隐私证明可以在不披露隐私输入的情况下聚合。

第六项优势是基础设施更加模块化。

Rollup、zkVM、跨链桥和应用可以生成证明，并将其纳入更大的证明系统。

第七项优势是提升可组合性。

系统不同部分生成的证明可以组合起来，共同证明更广泛的正确性。

递归 ZK 证明的局限

递归 ZK 证明功能强大，但并不简单。

与普通证明相比，递归 ZK 证明更难设计、审计和实现。

电路必须能够正确验证内部证明。

必须谨慎处理公共输入，确保最终证明证明的是正确陈述。

证明系统必须避免薄弱假设、不安全的参数选择和实现漏洞。

如果系统必须等待多层证明完成，递归证明也可能增加延迟。

某些递归系统需要专用曲线、曲线循环、可信设置选项或特定于证明系统的优化。

开发者还必须考虑数据可用性。

证明可以表明计算有效，但用户可能仍需要底层交易数据，以便重建状态或退出系统。

这对 Rollup 和其他扩容系统尤其重要。

递归 ZK 证明的安全风险

最大的风险是证明了错误的陈述。

如果电路验证了内部证明，却没有将内部证明的公共输出正确关联到外部证明的输入，递归过程就可能不安全。

另一个风险是信任未经仔细审计的验证器电路。

递归验证器中的漏洞可能影响所有基于它构建的证明。

另一个风险是数据可用性不足。

有效证明并不自动意味着用户能够获取独立恢复所需的全部数据。

另一个风险是升级控制。

如果协议可以轻易升级验证器合约或证明系统，用户可能面临治理风险或管理员密钥风险。

另一个风险是证明者中心化。

如果生成证明需要昂贵硬件或专用基础设施，可能只有少数实体能够生成证明。

递归 ZK 证明可以减少部分信任假设，但不能消除所有系统风险。

递归证明树

递归证明树是一种分层合并多个证明的结构。

在底层，许多小型证明分别验证一小部分计算。

在上一层，证明会验证这些较小证明的分组。

该过程持续进行，直到一个根证明代表整棵证明树。

这种模式类似于 Merkle 树将许多数据项压缩为一个根，但递归证明树压缩的是许多已验证的计算，并将其整合为一个最终证明。

证明树很有用，因为它允许并行处理。

许多证明者可以同时生成较低层级的证明。

随后，聚合证明者可以合并这些结果。

这可以让大型证明系统更适用于实际加密网络。

Rollup、共享证明者、zkVM 和证明市场都可以采用证明树设计。

递归 ZK 证明与数据可用性

递归 ZK 证明不能取代数据可用性。

证明可以表明状态转换有效，但用户可能仍需要该状态转换背后的交易数据。

对于 Rollup，数据可用性有助于用户验证余额、重建状态，并在需要时退出。

如果数据被隐藏或无法获取，即使证明有效，用户也可能无法充分保护自己。

因此，ZK-rollup 设计必须区分有效性和数据可用性。

有效性证明表明计算遵循了规则。

数据可用性则确保用户能够获取独立跟踪和恢复状态所需的信息。

递归证明可以降低有效性验证成本。

但它们不会自动解决所有数据访问问题。

安全的扩容系统必须同时处理证明正确性和数据可用性。

递归 ZK 证明与链上验证

链上验证是指区块链智能合约或协议验证证明。

递归 ZK 证明可以将多个证明检查合并为一次最终检查，从而提高链上验证效率。

这可能降低 Gas 成本或减少结算开销。

它还可以让原本无法承受直接链上验证成本的大型链下计算得以验证。

不过，链上验证仍取决于验证器合约或原生验证器实现。

验证器必须正确、高效，并与证明系统兼容。

如果验证器可以升级，用户应了解升级控制权掌握在谁手中。

如果验证器依赖可信设置，用户应了解该设置带来的假设。

如果验证器成本高昂，递归带来的优势可能会减弱。

优秀的递归证明系统会将最终验证成本纳入设计考量。

递归 ZK 证明与证明者去中心化

递归证明可以支持去中心化证明，但不能保证实现去中心化。

递归证明系统可以将工作拆分为多个较小任务，由许多证明者处理。

这可以让证明工作更容易分配给多台机器或多个参与者。

不过，某些证明任务仍可能需要高性能硬件、优化软件或专业知识。

如果只有一个运营方能够足够快速地生成证明，系统在实际运行中可能会中心化。

证明者去中心化很重要，因为 Rollup 或证明系统可能依赖及时生成证明。

如果唯一的证明者发生故障、受到审查或停止运行，用户可能会遇到延迟。

有些系统通过备用证明者、证明市场、共享证明网络或无需许可的证明设计来应对这一问题。

递归证明可以通过模块化证明工作来支持这些设计。

最终安全性仍取决于协议完整的证明和结算架构。

递归 ZK 证明的常见应用场景

递归 ZK 证明用于聚合 ZK-rollup 证明。

它们用于构建简洁型区块链，在链历史不断增长时仍保持验证过程精简。

它们用于需要证明大型程序执行过程的 zkVM。

它们用于聚合多笔隐私交易的隐私系统。

它们用于跨链验证，即一条链验证另一条链的状态。

它们用于需要证明链下工作的可验证计算应用。

它们用于多方证明构建，让不同参与方共同生成一个最终证明。

它们用于证明市场，由不同证明者生成大型证明工作负载中的部分证明。

它们还可用于身份系统，让用户在不透露不必要个人信息的情况下证明凭证或合规条件。

随着区块链系统日益模块化，递归证明可能会继续成为连接多个证明生成组件的重要技术。

开发者最佳实践

开发者应尽可能使用经过充分审查的证明系统和库。

开发者应明确界定每个递归证明要证明的陈述。

开发者应谨慎关联内部证明和外部证明之间的公共输入与输出。

开发者不应把递归当作弥补薄弱系统设计的捷径。

开发者应使用无效证明、格式错误的公共输入、边界情况和对抗性状态转换来测试递归电路。

开发者应将数据可用性与证明有效性分开考虑。

开发者应记录可信设置假设、验证器合约、升级控制和证明者要求。

开发者应设计系统，避免证明生成失败导致用户资金被不必要地困住。

开发者应邀请同时熟悉智能合约和证明系统的团队进行审计。

开发者应持续监控证明延迟、验证成本和证明者中心化程度。

用户最佳实践

用户应了解，递归 ZK 证明可以提升可扩展性和验证效率，但不能消除所有风险。

用户应查看协议是否说明证明机制、数据可用性和提现流程。

对于使用复杂 ZK 术语却缺少清晰文档的系统，用户应保持谨慎。

用户应关注审计、开源验证器代码、公开安全评估和透明的升级政策。

用户应了解协议依赖的是单个证明者、小型证明者群体，还是更去中心化的证明系统。

用户还应了解交易数据是发布在链上、存储在其他位置，还是由独立的数据可用性层处理。

有效的递归证明很有价值，但它只是完整安全模型的一部分。

用户应将递归 ZK 证明视为强大的密码学工具，而不是将其当作相关产品绝对无风险的保证。

常见问题

递归 ZK 证明是什么意思？

递归 ZK 证明是用于验证另一个零知识证明的零知识证明。

递归 ZK 证明为何对加密领域有用？

它们可以将多个证明或计算合并为一个紧凑证明，从而降低链上验证成本。

ZK-rollup 会使用递归 ZK 证明吗？

会。递归证明可以帮助 ZK-rollup 在基础链最终结算前聚合交易证明或批次证明。

递归 ZK 证明只用于隐私保护吗？

不是。它们可以支持隐私保护，也可用于扩容、证明聚合、轻客户端、zkVM 和可验证计算。

什么是“证明的证明”？

“证明的证明”是对递归的一种简单描述，指新证明用于证明旧证明有效。

递归 ZK 证明能让区块链更快吗？

它们可以通过减少验证工作来提高可扩展性，但实际速度还取决于证明时间、数据可用性、网络设计和结算规则。

递归 ZK 证明能取代数据可用性吗？

不能。递归证明可以证明有效性，但用户可能仍需要访问交易数据，才能重建状态或保护资金。

递归 ZK-SNARK 和递归 ZK-STARK 有什么区别？

递归 ZK-SNARK 使用基于 SNARK 的证明系统，而递归 ZK-STARK 使用基于 STARK 的证明系统。

递归证明可以在链上验证吗？

可以。许多系统都设计为由链上验证器合约或原生验证器验证最终递归证明。

递归 ZK 证明有风险吗？

如果电路、验证器逻辑、公共输入关联、数据可用性模型或升级控制设计不当，递归 ZK 证明可能存在风险。

结论

递归 ZK 证明是扩展和验证加密系统的重要密码学工具之一。

它们允许一个零知识证明验证另一个证明，从而形成一条紧凑的已验证计算链。

这使系统能够聚合多个证明、压缩区块链历史、支持 ZK-rollup、改进轻客户端，并证明复杂的链下计算。

在区块链扩容方面，递归证明可以降低链上验证成本，并支持证明者并行工作。

在隐私系统中，它们可以合并多个隐私证明，而不暴露敏感输入。

在简洁型区块链中，它们可以让用户无需下载完整的链历史即可验证当前状态。

递归 ZK 证明并非万能方案，因为数据可用性、验证器安全、证明者去中心化和电路正确性仍然至关重要。

最好将递归 ZK 证明理解为一种强大的证明组合方法，它让大型已验证系统更易于检查。

随着加密基础设施日益模块化并以证明为基础，递归 ZK 证明仍将是提升区块链可扩展性、隐私性和可验证性的核心技术。