Prover（证明者）

什么是加密货币中的 Prover？

Prover 是指生成密码学证明的个人、程序、节点、服务或硬件系统，用于证明某个陈述、计算、交易批次或状态转换有效。在加密货币领域，该术语最常用于零知识证明、有效性 Rollup、zkVM、隐私协议和可验证计算系统。Prover 的任务是完成创建证明所需的大量计算工作，让另一方能够以更低成本验证证明。另一方称为 Verifier（验证者）。Prover 可以证明某项计算正确完成，而无需让每个验证者都重新执行完整计算。这一理念对区块链扩容十分重要，因为公有区块链需要许多参与者就有效的状态变更达成一致。如果每个节点都必须完整重新执行每笔交易，网络可能会变慢且成本上升。借助证明系统，Prover 可以在链下执行或检查大量工作，再将精简的证明提交到链上。

Ethereum 的零知识证明文档指出，可验证计算允许节点在 Ethereum 之外执行交易，并提交证明来表明链下执行正确无误。

理解 Prover 最简单的方式是：它是生成数学凭证、证明某项计算正确完成的机器或参与者。

Prover 的工作原理

Prover 首先接收需要证明的陈述。陈述可以很简单，例如证明自己知道某个秘密值。也可以很复杂，例如证明数千笔 Layer 2 交易均按照协议规则处理。Prover 还需要使用输入数据。部分输入是公开的，验证者可以查看。部分输入是私有的，Prover 会使用这些输入，但不会直接披露。在许多证明系统中，私有输入称为 witness（见证）。随后，Prover 按照证明算法，将陈述、约束、公开输入和 witness 转换为证明。证明通常比原始计算小得多，也更容易快速验证。Verifier 使用验证算法检查证明。如果证明有效，Verifier 就会依据证明系统的规则接受该陈述为真。因此，区块链可以信任计算结果，而无需信任 Prover 本身。

Prover 与 Verifier

在证明系统中，Prover 和 Verifier 承担相反的职责。Prover 负责生成证明。Verifier 负责检查证明。通常 Prover 的工作更复杂，因为生成证明可能需要大量计算。Verifier 的工作通常更简单，因为验证证明的设计目标是快速、低成本。这种不对称性对区块链很有用：一个 Prover 可以在链下完成繁重工作，而许多节点或智能合约可以高效验证结果。例如，在 ZK-rollup 中，Prover 可以为大量交易生成有效性证明。随后，链上验证合约会检查证明，再接受 Rollup 的状态更新。

Ethereum 的ZK-rollup 文档说明，ZK-rollup 使用有效性证明在 Ethereum 上完成交易最终确认。

Verifier 无需相信 Prover 诚实，因为无效证明应无法通过验证。

Prover 与 Sequencer

Prover 与 Sequencer（排序器）并非同一角色。Sequencer 负责排列交易顺序，通常也会协助 Rollup 系统构建批次。Prover 则生成证明，证明批次或状态转换有效。在某些系统中，同一组织可能同时运营排序和证明基础设施。另一些系统会将排序和证明工作分散到不同服务、节点、市场或社区参与者。这一区分很重要，因为排列交易顺序与证明交易正确性是两种不同的权力。Sequencer 会影响交易顺序、延迟和用户体验。Prover 会影响证明能否及时提供、最终确认时间和基础设施成本。即使 Rollup 在技术上可靠，如果证明依赖单一运营方，仍可能面临中心化风险。

近期研究，例如CrowdProve 社区证明研究，探讨了如何将 ZK Rollup 的证明工作分配给许多规模较小的 Prover，而非仅依赖中心化基础设施。

零知识证明中的 Prover

在零知识证明中，Prover 试图让 Verifier 相信某个陈述为真，同时不披露该陈述真实性以外的额外信息。Prover 可能掌握私密秘密、私密交易数据、私密身份属性、私密计算结果或私密 witness。证明只应披露系统设计要求披露的信息。例如，用户可以证明自己知道有效密码，而不透露密码本身。在加密货币领域，用户可以证明某笔交易符合规则，而不披露所有私密细节。并非 Rollup 使用的每种证明都主要用于隐私保护。许多 Rollup 使用有效性证明，主要是为了扩容和确保正确性，而非隐藏所有交易详情。因此，当证明旨在验证正确执行而非实现全面隐私时，有些人会使用范围更广的“有效性证明”一词。Prover 仍然是生成证明的组件。证明用于隐私、扩容还是两者兼顾，取决于协议设计。

ZK-Rollup 中的 Prover

在 ZK-Rollup 中，Prover 会生成证明，表明一批链下交易已被正确处理。Rollup 会在基础链之外执行大量交易。随后，它会向基础链提交压缩数据和有效性证明。基础链通过验证证明来代替重新执行批次中的每笔交易。这可以减少链上计算并提升可扩展性。Prover 是 ZK-Rollup 最重要的组成部分之一，因为用户依赖证明来完成状态更新的最终确认。如果生成证明的速度较慢，最终确认可能延迟。如果生成证明的成本较高，Rollup 的运营成本可能上升。如果证明生成过程中心化，Rollup 可能过度依赖单一基础设施提供方。如果证明生成失败，Rollup 可能难以提交新的有效状态更新。因此，Prover 的设计、性能、去中心化程度和可靠性都是 Layer 2 开发中的重要议题。

zkVM 中的 Prover

zkVM 是一种零知识虚拟机，可以证明程序执行正确。开发者无需为每项任务单独编写电路，而是可以在虚拟机中运行代码，并生成证明来表明代码执行正确。

RISC Zero 开发者文档将可验证计算描述为一种通过密码学方式确信特定数据输出由特定算法生成的方法。

在 zkVM 中，Prover 运行程序、记录执行过程，并生成执行证明。Verifier 随后可以检查证明，而无需重新运行整个程序。这种模式可以让 ZK 开发更易上手，因为开发者可以使用熟悉的编程语言或虚拟机目标。zkVM Prover 可用于 Rollup、跨链桥、身份系统、隐私应用、可验证 AI 工作流、可验证游戏和链下计算。不过，zkVM 证明可能需要大量资源。其性能取决于程序规模、内存用量、证明系统、硬件、递归设计和优化方案。

STARK 系统中的 Prover

基于 STARK 的系统使用一种证明类型，其验证无需依赖其他部分证明系统所采用的相同可信设置假设。在 STARK 系统中，Prover 会根据代数约束和执行轨迹数据，将计算转换为证明。该证明可以表明程序或交易批次遵循了规定规则。

Starknet 的SHARP 文档介绍了用于验证 SHARP 所生成 STARK 证明的链上验证合约。

SHARP 是共享证明基础设施的一个示例，可聚合并证明多个程序或应用的执行过程。STARK Prover 以良好的可扩展性和透明性优势而闻名。根据具体构造，它们生成的证明也可能比某些 SNARK 系统更大。与任何证明系统一样，实际取舍取决于证明生成时间、验证成本、证明大小、安全假设和开发者体验。Prover 承担了大部分技术复杂性，使 Verifier 能够检查精简的证明。

SNARK 系统中的 Prover

SNARK 系统使用简洁证明，这类证明体积可能很小且验证速度很快。在 SNARK 系统中，Prover 会生成精简证明，证明某项计算满足一组约束。许多 SNARK 系统需要可信设置，但较新的设计可能会减少或改变这一要求。SNARK Prover 通常需要在设置阶段生成的证明密钥。Verifier 使用验证密钥检查证明。当链上验证成本必须非常低时，SNARK Prover 可能很有用。这很重要，因为基础层区块链会对计算和存储收取费用。体积小、验证成本低的证明可以让高级应用更实用。不过，Prover 生成证明仍可能成本高昂。基于 SNARK 的应用设计必须权衡证明大小、证明生成时间、可信设置假设和开发复杂度。

Witness、公开输入与私有输入

Prover 通常同时处理公开输入和私有输入。公开输入是允许 Verifier 查看的数据。私有输入是 Prover 会使用、但不会直接披露的数据。私有输入通常称为 witness。例如，在隐私身份证明中，公开输入可以是年龄门槛，而私有 witness 则可以是用户的实际出生日期或凭证数据。在 Rollup 证明中，公开输入可能包括旧状态根、新状态根、批次承诺或协议参数。根据设计，witness 可能包括交易详情、执行轨迹、Merkle 路径、签名或中间计算数据。Prover 使用 witness 生成证明。Verifier 检查证明是否与公开输入相符。安全的证明系统不应允许 Prover 为虚假陈述生成有效证明。

电路与约束

许多证明系统要求将计算表示为电路或一组约束。电路以证明系统能够理解的形式描述需要证明的内容。约束则定义有效输入和计算步骤必须满足的规则。例如，电路可能要求正确计算哈希、验证签名有效，或要求余额更新符合协议规则。Prover 必须证明存在满足所有约束的 witness。如果 witness 不满足约束，Prover 就不应能够生成有效证明。电路设计是 ZK 开发中最困难的环节之一。编写不当的电路可能会意外证明错误的内容。电路也可能正确但效率低下，导致 Prover 速度慢或成本高。Prover 的良好性能通常始于良好的电路设计。

执行轨迹

部分证明系统使用执行轨迹，而非传统的特定应用电路。执行轨迹是程序或虚拟机执行计算步骤的记录。Prover 利用轨迹证明每一步都遵循机器或协议规则。这种模式常见于 STARK 系统和 zkVM 系统。轨迹生成可能成为主要性能瓶颈，因为大型程序会产生庞大的轨迹。近期关于 ZK 虚拟机的研究重点之一，是改善轨迹生成、证明流水线和硬件加速。高效轨迹有助于降低 Prover 成本和延迟。对于 Rollup，更快生成轨迹意味着可以更快提交证明并完成结算。对于应用，更快的轨迹生成可以让可验证计算更适合实际用户。Prover 负责将原始执行过程转换为可用于证明的数据。

Prover 性能

Prover 性能是零知识加密系统中最重要的实际问题之一。生成证明可能需要大量 CPU、GPU、内存、存储和专用硬件资源。有些证明系统生成证明较快，但验证较慢。另一些系统生成证明较慢，但能得到更小或验证成本更低的证明。Rollup 团队通常会投入大量工程资源优化 Prover 流水线。更快的 Prover 可以缩短结算延迟。成本更低的 Prover 可以降低用户成本。可扩展性更强的 Prover 可以支持更多交易和更复杂的应用。Prover 性能也会影响去中心化程度，因为如果证明需要非常昂贵的硬件，能够运行 Prover 的参与者就会减少。这可能使网络更加依赖专业运营方。

Prover 去中心化

Prover 去中心化是指证明生成不由单一参与方控制。在早期 ZK 系统中，证明基础设施往往是中心化的，因为相关技术复杂、运营成本高。许多项目希望随着时间推移，让证明过程更加分布式。分布式证明可以通过多个 Prover、证明市场、共享证明网络、社区证明或硬件提供方之间的竞争实现。去中心化证明可以降低审查风险、活跃性风险和对单一运营方的依赖。但这也会带来协调方面的挑战。系统必须分配证明任务、验证 Prover 的工作、向 Prover 付款、防止垃圾任务、处理失败任务，并在需要时保护敏感 witness 数据。社区证明研究正在探索许多较小规模的机器能否共同为 Rollup 生成证明。如果经济机制和安全设计可行，这或许能让证明基础设施更加开放。Prover 去中心化不只是技术问题，还取决于激励、治理、硬件获取和软件易用性。

Prover 市场

Prover 市场是不同 Prover 为应用生成证明并在其中竞争或协作的系统。Rollup、跨链桥、zkVM 应用或隐私系统可以向 Prover 网络提交证明任务。Prover 可以竞价承接任务，也可以由协议规则选出。Prover 生成有效证明后，可能会获得报酬。Prover 市场可以通过促进竞争来降低成本。它也可能提升可靠性，因为应用不再受限于单一证明服务器。不过，Prover 市场需要完善的验证机制，以拒绝无效证明并处理失败任务。如果证明任务包含敏感 witness 数据，市场还需要隐私保护措施。如果任务只涉及公开数据，有些证明工作可以安全外包。其他任务则需要机密计算、加密 witness、可信硬件或谨慎的协议设计。

递归证明

递归证明是指用一个证明验证另一个证明，再对这一验证过程生成证明。这听起来比较抽象，但对扩容系统非常有用。Prover 可以生成许多较小的证明，再将它们合并为一个较大的证明。这样可以降低验证成本，并减少提交到链上的数据量。递归证明可以帮助 Rollup 聚合多个交易批次。它也可以帮助 zkVM 将长时间计算分成较小片段进行证明。递归证明能够提升可扩展性，但也会增加技术复杂度。Prover 流水线必须处理证明组合、验证电路、聚合计划和性能权衡。递归证明设计也可能影响延迟，因为最终证明可能需要等待前序证明完成。用户通常看不到递归证明，但它可能影响速度、费用和最终确认。

证明聚合

证明聚合是将多个证明合并为一个证明或一次验证流程。Prover 或聚合器可以接收许多独立证明，并生成一个代表全部证明的单一证明。这样可以降低链上验证成本，因为基础链只需验证一个聚合证明，而非多个独立证明。证明聚合适用于 Rollup、隐私池、批量结算和跨链消息系统。它也支持共享证明基础设施，让多个应用共用同一条证明流水线。代价是聚合可能增加延迟，因为系统可能要等待足够多的证明后才能进行批处理。它也可能让系统依赖聚合器或共享 Prover 服务。优秀的聚合设计需要平衡效率、延迟、去中心化程度和可靠性。证明聚合是 Prover 正在成为加密基础设施重要组成部分的原因之一。使用 ZK 证明的应用越多，高效聚合就越有价值。

Prover 活跃性

Prover 活跃性是指证明系统在需要时持续生成证明的能力。如果 Rollup 需要证明来完成批次结算，Prover 停机可能会延迟结算。如果跨链桥需要证明才能释放资金，Prover 停机可能会延迟提现。如果隐私应用需要证明才能执行用户操作，Prover 停机可能会导致用户无法完成交易。活跃性不仅关乎证明系统在数学上是否安全。它还取决于实际基础设施能否在高负载、故障、攻击和硬件失灵时持续运行。冗余、分布式证明、任务队列、备用 Prover、监控和明确的应急流程都有助于提高 Prover 活跃性。用户应了解，ZK 系统在正确性方面可以最大限度减少信任需求，但及时运行仍可能依赖证明基础设施。如果没有人生成证明，有效证明也无济于事。因此，Prover 的运营是协议可靠性的一部分。

Prover 健全性

健全性是指不诚实的 Prover 不应能够让 Verifier 相信虚假陈述为真。在加密货币领域，健全性至关重要，因为虚假证明可能导致无效状态转换、虚假提现、错误余额或未经授权的操作。即使速度很快，健全性较弱的证明系统也很危险。健全性取决于密码学假设、实现质量、参数选择、电路正确性和验证者正确性。Prover 可能具有恶意，但 Verifier 应拒绝无效证明。这正是证明系统功能强大的主要原因。协议无需相信 Prover 诚实。协议只需确保证明系统和 Verifier 安全。不过，如果电路证明的是错误陈述，那么证明对该电路而言可能有效，却仍无法保护应用。必须同时考虑证明系统层面和应用设计层面的健全性。

Prover 完备性

完备性是指诚实的 Prover 应能够为真实陈述生成证明。如果计算有效且 Prover 拥有正确的 witness，证明系统就应生成可被 Verifier 接受的证明。完备性很重要，因为如果系统会拒绝有效证明或无法可靠生成证明，就无法实际使用。对于 Rollup，完备性不足可能导致有效交易批次无法完成结算。对于隐私应用，诚实用户可能因此无法证明其操作有效。对于 zkVM，程序可能明明正确，却因实现错误或资源限制而无法生成证明。完备性取决于软件正确性、充足的内存和计算资源、兼容的证明参数以及稳定的基础设施。实践中，开发者会对证明系统进行大量测试，确保其能够可靠证明有效工作负载。Prover 既要防止生成虚假证明，也要能实际处理真实证明。优秀的 Prover 设计需要兼顾安全性和易用性。

Prover 的零知识属性

零知识是指证明不会泄露被证明陈述为真以外的不必要信息。当 witness 含有私密数据时，这一属性十分重要。Prover 可能掌握私钥、隐藏的交易金额、私密身份属性或机密计算输入。零知识证明应让 Prover 能够证明所需陈述，而不披露秘密本身。加密货币领域使用的有效性证明并非都需要强隐私保护。有些系统采用证明技术，主要是为了降低验证成本。需要隐私保护时，开发者必须谨慎设计电路、公开输入、元数据处理和用户界面。即使证明具有零知识属性，周边数据仍可能泄露信息。例如，时间信息、钱包地址、IP 数据或交易模式仍可能暴露用户行为。Prover 可以通过数学方式保护 witness，但整个应用还必须在实际运营层面保护隐私。

Prover 硬件

根据证明系统和工作负载，Prover 可能使用 CPU、GPU、FPGA、ASIC 或云基础设施。生成证明可能涉及有限域计算、多项式承诺、哈希、快速傅里叶变换和轨迹处理等计算密集型操作。这些任务可以受益于并行计算和专用硬件。硬件加速可以缩短证明生成时间并降低成本。但如果只有资金充足的运营方才能负担最好的证明硬件，也可能产生中心化压力。一些项目通过提高软件效率并支持通用硬件来缓解这一问题。另一些项目则使用专用证明集群来实现高吞吐量。硬件方面的取舍取决于网络目标。追求最高吞吐量的系统可能会接受更专业化的证明基础设施。希望广泛参与的系统则可能优先选择可在更多易于获取的设备上运行的 Prover 设计。

Prover 费用与经济机制

运行 Prover 需要成本。硬件、电力、带宽、工程开发、维护和监控都需要投入。在 Rollup 中，证明成本可能由交易手续费、协议收入、补贴或运营方资金支付。在 Prover 市场中，Prover 可能会因完成证明任务而直接获得报酬。Prover 的经济机制很重要，因为高昂的证明成本可能推高用户费用。这也可能限制可实际运行的应用类型。如果每项操作都需要昂贵的证明生成，游戏、社交应用或小额支付系统可能难以正常运行。开发者通常会优化电路、批量处理工作、聚合证明并使用递归，以降低每笔交易的证明成本。用户可能看不到单独列出的 Prover 费用，但会通过交易成本、结算延迟或应用限制感受到影响。高效证明是让 ZK 应用走向主流的关键之一。

Prover 的安全风险

第一项风险是实现漏洞。存在漏洞的 Prover 可能生成错误证明、在高负载下失效或泄露敏感 witness 数据。第二项风险是证明过程中心化。如果只有一个运营方能生成证明，该运营方发生故障时，系统可能停机或受到审查。第三项风险是 witness 泄露。如果证明服务接收私有输入，安全措施不足可能导致用户数据暴露。第四项风险是电路漏洞。如果电路没有落实预期规则，Prover 仍可能为错误电路生成有效证明。第五项风险是硬件遭到入侵。被攻陷的证明设备可能泄露秘密、延迟任务或攻击应用基础设施。第六项风险是经济机制失效。如果 Prover 得到的报酬不足，证明能力可能供不应求。第七项风险是升级风险。更改证明软件、电路或验证合约可能引入新的漏洞。

Prover 与数据可用性

Prover 证明正确性，但不会自动保证数据可用性。数据可用性是指用户或节点能够访问重建或验证系统状态所需的交易或状态数据。这一点在 Rollup 中尤为重要。有效性证明可以表明状态转换有效，但用户也需要足够的数据来查看余额、退出仓位或重建状态。不同的 Rollup 和扩容设计会采用不同方式处理数据可用性。有些设计会将数据发布到基础链。有些设计会使用独立的数据可用性层。还有些设计会使用委员会或其他模型。Prover 的职责是证明某项陈述，而不是独自解决所有可用性问题。安全的扩容系统既需要有效证明，也需要可用数据。

Prover 与最终确认

最终确认是指交易或状态更新按照网络规则被接受为已结算状态。在基于有效性证明的系统中，生成证明的速度可能影响最终确认时间。批次可能很快在 Layer 2 上执行，但在基础链上的最终结算可能需要等待证明。Prover 越快，结算就可能越早完成。如果 Prover 速度较慢或负载过高，用户可能需要更长时间等待最终确认或提现。递归证明和证明聚合可以提升效率，但也可能增加批处理延迟。最终确认还取决于基础链的出块时间、确认规则和验证合约执行情况。Prover 只是最终确认流程中的一个环节。不过，Prover 速度往往是 ZK 系统中最明显的瓶颈之一。更好的 Prover 可以让 ZK 应用更快速、更可靠。

Prover 与跨链桥

跨链桥可以利用 Prover 证明来自一条链的事件、状态转换或消息。基于证明的跨链桥可以让一条链验证另一条链上的事实，而无需信任中心化签名者群体。例如，Prover 可以生成证明，表明某笔交易、状态根或消息在源链上有效。目标链上的验证合约随后可以检查该证明。与某些跨链桥模型相比，这可以减少信任假设。不过，基于证明的跨链桥仍然复杂。它们必须处理链重组、最终确认假设、验证者正确性、数据可用性、证明成本和升级风险。Prover 可以改善跨链桥的信任假设，但不会自动让跨链桥设计变得安全。用户仍应将跨链系统视为高风险基础设施。跨链桥安全取决于整体架构，而不只是是否使用了 Prover。

Prover 与隐私

在注重隐私的加密应用中，Prover 可以帮助用户证明自己遵守规则，同时隐藏敏感信息。例如，用户可以证明自己持有某项凭证，而不披露凭证全部内容。用户可以证明交易余额有效，而不透露所有私密交易详情。用户可以证明自己属于某个群体，而不披露具体是哪位成员。Prover 使用私有输入生成证明。Verifier 使用公开规则检查证明。这使选择性披露成为可能。不过，隐私保护不只取决于证明本身。元数据、网络活动、时间信息、地址重复使用、浏览器指纹和应用日志仍可能泄露信息。强大的隐私系统必须保护用户完整使用流程，而不只是密码学 witness。

Prover 与合规

Prover 可以支持更注重合规的加密设计，让用户在不披露不必要私密数据的情况下证明相关事实。例如，用户可以证明自己符合资格要求，而无需在链上披露完整身份证件。协议可以证明计算遵循了一套规则，而不暴露私密业务数据。金融应用可以证明状态转换符合会计约束，而不公开所有内部记录。这并不意味着零知识证明可以自动解决所有合规问题。法律要求因司法管辖区和使用场景而异。部分规则仍可能要求保存记录、审计、身份核验、报告或披露。Prover 可以减少不必要的数据暴露，但不能取代法律分析。良好的合规设计应结合密码学、政策、治理和用户同意。Prover 可以让选择性验证成为可能，但仍需要由人来决定必须证明什么。

Prover 的优势

Prover 的首要优势是可扩展性。Prover 可以将大规模计算压缩为更易验证、成本更低的证明。第二项优势是隐私保护。如果证明系统按照零知识方式设计，Prover 可以在不披露私密数据本身的情况下证明相关事实。第三项优势是减少信任需求。只要无效证明会被拒绝，Verifier 就无需信任 Prover 诚实。第四项优势是互操作性。证明可以帮助一个系统验证另一个系统中的事实。第五项优势是可审计性。证明可以提供数学证据，表明计算遵循了既定规则。第六项优势是自动化。智能合约可以验证证明并据此执行操作，无需人工审核。第七项优势是效率。证明聚合和递归可以降低多个交易或应用中重复验证的成本。

Prover 的局限

第一项局限是成本。生成证明可能需要大量计算资源。第二项局限是延迟。证明生成需要时间，可能延迟结算或提现。第三项局限是复杂性。Prover 系统需要专业密码学、工程开发和安全审查。第四项局限是中心化压力。高硬件要求可能让许多独立参与者难以运行 Prover。第五项局限是依赖电路。证明只能证明电路或程序实际检查的内容。第六项局限是证明之外的隐私泄露。零知识证明不会自动隐藏元数据，也无法弥补糟糕的应用设计。第七项局限是升级风险。更改证明软件、电路或验证合约可能带来新的安全假设。

用户应如何理解 Prover

大多数用户不会直接与 Prover 交互。他们使用的钱包、Rollup、跨链桥、隐私应用或去中心化应用，可能在后台使用 Prover。用户仍应了解 Prover 的作用，因为它会影响速度、费用、最终确认和信任假设。如果 Rollup 依赖一个中心化 Prover，用户应了解该 Prover 离线后会发生什么。如果隐私应用使用远程证明服务，用户应了解私有数据是否会发送给该服务。如果跨链桥依赖证明，用户应了解证明验证了什么、又没有验证什么。用户还应查看验证合约是否经过审计，以及证明系统是否有明确的安全模型。Prover 并不是万能的安全保障。只有在证明系统、电路、Verifier、数据可用性和治理均设计正确时，Prover 才有价值。用户应把证明视为安全体系中的一层，而非整个系统。

开发者最佳实践

开发者应明确界定 Prover 需要证明的陈述。开发者应设计电路或程序，准确落实预期规则。开发者应使用经过充分审查的证明系统，除非获得专家审查，否则应避免自创密码学方案。开发者应针对真实工作负载、边界情况和故障条件测试证明生成。开发者应对 Prover 耗时、内存用量、硬件要求和验证成本进行基准测试。涉及敏感用户数据时，开发者应保护私有 witness。开发者应说明公开输入，让用户和审计人员了解 Verifier 实际检查的内容。在可能的情况下，开发者应将 Prover 基础设施与受信任的管理权限分离。开发者应为 Prover 停机、任务重试、监控和紧急备用方案做好准备。更改电路、证明密钥、验证合约或 Prover 软件时，开发者应说明升级风险。

关于 Prover 的常见误解

一种误解是必须信任 Prover。在设计良好的证明系统中，即使 Prover 不诚实，Verifier 也应拒绝无效证明。另一种误解是 Prover 总能提供隐私保护。有些 Prover 生成有效性证明是为了扩容，并不会隐藏所有交易数据。另一种误解是生成证明成本很低。证明生成的成本可能远高于验证，且可能需要专用基础设施。另一种误解是有效证明能够证明应用的所有情况。证明只能证明电路或程序中编码的特定陈述。另一种误解是 Prover 去中心化已在所有系统中实现。许多系统仍在努力建设更开放、去中心化的证明基础设施。另一种误解是用户完全无需关注 Prover。用户可能不会运行 Prover，但 Prover 设计会影响提现、最终确认、费用、隐私和应用可靠性。

常见问题

加密货币中的 Prover 是什么意思？

Prover 是生成密码学证明的参与者、程序、节点或服务，用于证明某项陈述、计算或状态转换有效。

零知识证明中的 Prover 是什么？

在零知识证明中，Prover 会生成证明，让 Verifier 相信某项陈述为真，同时不披露不必要的私密信息。

Prover 与 Verifier 有什么区别？

Prover 负责生成证明，Verifier 负责检查证明是否有效。

Prover 为什么对 ZK-Rollup 很重要？

Prover 会生成有效性证明，使交易批次能够在基础链上结算，而无需每个节点重新执行所有交易。

Prover 和 Sequencer 是同一角色吗？

不是。Sequencer 负责排列交易顺序，Prover 则生成证明，验证执行正确或状态转换有效。

Prover 总会隐藏私密数据吗？

不会。有些 Prover 主要用于扩容和确保正确性；是否保护隐私，取决于证明系统和应用是否按照零知识方式设计。

不诚实的 Prover 能生成虚假证明吗？

安全的证明系统应能防止不诚实的 Prover 为虚假陈述生成有效证明。

为什么证明生成成本高？

证明生成可能需要大量计算、占用大量内存的轨迹生成、多项式运算、哈希、递归和专用硬件，因此成本较高。

证明中的 witness 是什么？

Witness 是 Prover 用来生成证明的私有或内部数据，不一定会向 Verifier 披露。

什么是递归证明？

递归证明是证明另一个证明有效的过程，有助于将多个证明合并为更小或更高效的证明。

如果 Rollup 的 Prover 离线会怎样？

如果 Rollup 依赖该 Prover，证明提交和最终结算可能会延迟，直到证明能力恢复或启用备用 Prover。

Prover 可以去中心化吗？

可以。去中心化证明是正在发展的研究领域，但需要解决任务分配、付款、可靠性、隐私和验证等问题。

结语

Prover 是现代加密证明系统中最重要的基础设施角色之一。它生成密码学证明，使 Verifier 无需重做所有底层工作，就能确认陈述、计算、交易批次或状态转换有效。Prover 是零知识证明、ZK-Rollup、zkVM、STARK 系统、SNARK 系统、证明聚合、递归证明、隐私协议、跨链桥和可验证计算的核心组成部分。Prover 的主要价值在于将繁重计算从 Verifier 一侧转移出去，同时保持验证过程可信。这可以提高可扩展性、减少链上工作、支持隐私保护并实现新的应用设计。不过，Prover 也会带来现实挑战。生成证明可能成本高、速度慢、依赖大量硬件资源、运营复杂，有时还会出现中心化。证明的价值取决于它所证明的陈述、所检查的电路或程序、验证它的 Verifier，以及确保证明服务持续运行的基础设施。对用户而言，最重要的是：Prover 能提高密码学验证效率，但无法消除 Rollup、跨链桥、隐私应用或智能合约系统中的所有风险。对开发者而言，最重要的是：Prover 设计必须安全、高效、经过充分测试、注重隐私并有清晰文档。理解 Prover 最简单的方式是：它负责完成困难的数学工作，让加密网络的其他部分能够快速、无需信任地验证结果。