去中心化 ZK 证明者网络：证明市场如何影响 Rollup 结算与跨链报价

摘要：证明者网络不是把 GPU 接到 Rollup 后端那么简单

ZK-Rollup 的瓶颈常被概括为“证明生成很贵”，但这句话只说到一半。真正影响结算、跨链路由和用户退出路径的，是证明任务在一个开放市场里如何被切分、竞价、提交、聚合和验证。去中心化 ZK 证明者网络（Decentralized Prover Network）的目标，是把原本由单一运营方维护的 Prover 集群，改造成可由外部算力参与的证明市场；它要同时处理可验证计算、任务调度、经济激励、防抢跑、抗审查和硬件中心化。本文的核心结论是：Proof-of-Useful-Work 不是传统挖矿的同义词，它更像一个带截止时间、可验证输出、可罚没保证金的实时计算市场。设计好时，它能降低 Rollup 证明延迟和单点故障；设计坏时，它会把证明生产变成少数硬件巨头、聚合器和任务分发者之间的封闭博弈。

问题边界：本文讨论哪些角色，哪些风险不展开

系统中至少有六类角色。Rollup 或应用链是证明需求方，记为 `R`；任务分发器把一个待证明执行轨迹拆成若干证明任务，记为 `D`；证明者集合为 `P = {p1, p2, ... pn}`；聚合器负责把分段证明压缩成根证明，记为 `A`；链上验证合约检查最终 proof 与 public input；跨链交换或路由系统则把该 proof 的延迟和可信状态转化成报价风险。攻击者不一定是外部黑客，也可能是高算力证明者、聚合器、任务分发器、排序器或它们的合谋集合。

本文不讨论如何从零实现某个 SNARK 或 STARK，也不把某个项目的测试网机制写成整个行业已经定型的标准。Succinct、RISC Zero/Boundless、Aleo、Mina、Scroll、以太坊 ZK-Rollup 文档都提供了不同侧面的参考：有的强调通用可验证计算，有的强调 zkVM receipt，有的强调递归证明，有的强调 Rollup 证明管线。把这些材料放在一起看，去中心化证明者网络的难点不是单个 proof 是否可验证，而是网络能否在开放环境中持续交付“及时、不可抄袭、可聚合、可罚没”的证明结果。

信任假设也要划清。验证合约仍然只信密码学证明，不信证明者身份；任务市场则必须信链上或链下的承诺、保证金、时间戳和仲裁逻辑；调度层还要处理网络延迟、节点离线、硬件差异和价格波动。换句话说，安全性来自 proof system，活性来自市场和调度，抗垄断来自奖励函数和任务分配规则。三者不能互相替代。

证明任务模型：从单个 proof 到可交易的计算单元

一个可交易的证明任务可以抽象为：

`T_i = (programHash, inputCommitment, publicInputs, traceShard, deadline, reward, bond, domain)`

`programHash` 绑定被证明的程序或电路；`inputCommitment` 绑定私有 witness 或执行轨迹承诺；`publicInputs` 绑定状态根、区块号、交易批次哈希等公开输入；`traceShard` 标识分段范围；`deadline` 约束结算时间；`reward` 是任务奖励；`bond` 是证明者保证金；`domain` 用于防止跨任务重放。证明者提交的不是“我做过计算”这句话，而是可由 verifier 检查的 proof 或可被上层聚合的子 proof。

Proof-of-Useful-Work 的“Useful”来自两点。第一，计算结果必须能被目标协议直接消费，例如生成某个 Rollup batch 的有效性证明，而不是只消耗哈希算力。第二，奖励必须与任务完成质量相关，而不是单纯奖励最早广播者。一个最小化的收益函数可以写成：

`profit(p_j, T_i) = reward_i + urgencyPremium_i - cost(p_j, T_i) - invalidPenalty - latenessPenalty - plagiarismRisk`

其中 `cost` 不是常数，它由证明系统、硬件、内存带宽、并行度、网络延迟和电价共同决定。如果奖励只按“最快提交”结算，任务会自然流向最强硬件和最低延迟机房；如果奖励过度平均，又会降低尖峰时段的证明供给。合理的设计通常要把基础奖励、紧急溢价、保证金、迟到惩罚、无效 proof 惩罚和长期声誉放在一起，而不是只设计一个拍卖价格。

分段证明与树状聚合：调度层真正决定延迟

Rollup 证明往往不是一个不可拆的黑盒。执行轨迹可以按区块、交易批、内存段、递归层级或电路模块切分。分段后，每个证明者处理 `T_i` 的一个 shard，聚合器再把 `proof_i` 组合成更小的递归 proof。抽象流程是：

```text for batch B: shards = split_trace(B, policy) for shard in shards: assign_prover(shard, reward, deadline, bond) childProofs = collect_valid_proofs(shards) rootProof = aggregate_tree(childProofs) submit(rootProof, publicInputs) ```

这段伪代码看起来简单，但工程上的关键变量是树的形状。若每个 shard 大小相近，二叉树聚合的深度约为 `O(log m)`；若 shard 负载差异很大，最后一个慢 shard 会成为 critical path。实际调度要考虑 straggler：同一个 shard 是否发给两个证明者竞争？如果发给多个，网络会多付冗余成本；如果只发给一个，离线或低估难度会拖慢整个根证明。证明市场里所谓“出块博弈”，本质上是 deadline、冗余度、聚合树深度和奖励曲线之间的优化问题。

更细的切分并不总是更好。切得太细会增加承诺数量、任务元数据、网络通信和聚合开销；切得太粗会降低并行度，让单个证明者的硬件优势被放大。对于需要 MSM、NTT、FRI、Sumcheck 或递归验证的系统，瓶颈还可能从 CPU 转移到 GPU 显存、PCIe 传输、内存带宽或证明对象序列化。一个开放证明网络若只公布“平均证明时间”，而不公布 shard 粒度、失败重试、聚合延迟和 p95/p99 数据，工程上很难评估它对结算的真实价值。

防抢跑：提交 proof 之前要先保护计算成果

证明市场最容易被低估的攻击面，是结果抢跑。慢速但诚实的证明者可能先完成大部分计算并在网络中泄露中间对象、proof blob 或聚合输入；高延迟优势节点看到结果后抢先广播，领取奖励。这里的“抢跑”不是 AMM 交易意义上的价格夹击，而是可验证计算成果的署名和归属被夺取。

一个常见防线是两阶段承诺-提交（commit-and-reveal）。第一阶段，证明者提交 `C = H(taskId, proverKey, proofDigest, nonce, domain)` 并锁定保证金；第二阶段，在 reveal 窗口内提交 proof、nonce 和证明者签名。合约或仲裁器检查 digest 与 proof 是否匹配、proof 是否验证通过、提交时间是否在窗口内。这样做至少阻止了“看到明文 proof 后立即复制提交”的简单抢跑。

但 commit-and-reveal 不是万能解。若任务公开输入足够完整，强证明者仍可独立重算并更快 reveal；若 reveal 窗口太长，会增加结算延迟；若窗口太短，网络抖动会误伤诚实节点。更稳健的设计会把 proof 绑定到证明者身份或会话密钥，例如在 public input 中加入任务域分离信息，或者要求证明者提交可验证签名的 receipt。对于递归聚合，还要防止子 proof 被聚合器无授权复用。工程上可以把子 proof 看成带所有权标签的对象：没有正确授权，聚合器可以验证 proof，却不能把它用于领取对应 shard 的奖励。

另一类风险是中间系数或 witness 派生物泄露。本文不讨论可被滥用的窃取流程，只强调防御边界：证明者节点应把高价值中间态留在本地隔离进程或受控内存里；任务网络不应要求过早公开多项式系数、trace fragment 或可重构 witness 的对象；聚合器只应接收验证所需的最小 proof 和承诺。开放网络的安全设计要假设“消息会被复制、延迟会被操纵、广播顺序会被观察”，而不是假设所有参与者都按善意 API 调用。

硬件中立不是平均主义，而是避免奖励函数变成 ASIC 入口券

ZK 证明天然偏向专业硬件。不同证明系统的热点不同：Groth16/Plonk 系列常见瓶颈包括 MSM、FFT/NTT 和多项式承诺；STARK/FRI 路线更看重哈希、内存访问和低度测试；zkVM 还会引入执行 trace 生成、guest 程序约束化和 receipt 压缩。硬件优势本身不是问题，问题是奖励函数是否把网络活性绑定在少数机房和私有优化上。

所谓硬件无关基准（hardware-agnostic benchmarking）不能理解成忽略硬件差异。更现实的做法，是把任务分成多种难度和时限，让中等算力节点在非尖峰任务、长 deadline 任务、冗余验证任务或低优先级聚合任务中仍有正期望收益。一个可能的奖励结构是：

- `baseReward` 保证普通任务的最低供给； - `urgencyPremium` 支付尖峰结算需求； - `diversityWeight` 对长期在线、不同网络区域、不同硬件类别给予轻量加权； - `slashing` 惩罚无效 proof、承诺不 reveal、重复抄袭和恶意拖延； - `reputationDecay` 防止早期大节点永久垄断排序权。

这里的取舍很硬。奖励太偏多样性，会牺牲最快证明时间；奖励太偏速度，会把网络推向中心化；惩罚太强，会吓退边缘节点；惩罚太弱，会让垃圾任务和无效 proof 消耗聚合器资源。Proof-of-Useful-Work 的经济学难点，不是证明“算力越多越安全”，而是让算力供给在不同负载、不同延迟和不同硬件成本下仍然有足够分散度。

失败模式：证明网络会怎样拖慢或污染结算路径

第一类失败是 prover withholding。证明者赢得任务或拿到关键 shard 后不提交结果，试图等待更高奖励、影响某个 Rollup 批次结算，或让竞争对手错过 deadline。防御方式包括保证金、超时重分配、冗余派单和任务可替换性，但这些都会提高成本。

第二类失败是 invalid proof spam。恶意节点提交无法验证的 proof 或畸形对象，消耗聚合器验证、存储和网络资源。链下网关必须做快速预检，链上合约要限制可提交对象大小和罚没规则，否则攻击者可以把“开放证明市场”变成廉价 DoS 面。

第三类失败是 result plagiarism。复制 proof、复制子 proof 或抢先 reveal 会破坏诚实节点收益，长期看会让中小证明者退出。commit-and-reveal、proof ownership、会话签名和聚合授权可以降低风险，但会增加协议复杂度和延迟。

第四类失败是 aggregator censorship。聚合器可以选择性忽略某些证明者结果，把奖励导向关联节点，或延迟聚合特定 batch。多聚合器、可挑战的任务日志、链上结算证明和公开审计轨迹可以缓解，但如果任务分发器本身集中，审查风险仍然存在。

第五类失败是 stale proof。Rollup 状态根、输入承诺或排序器输出发生变化后，证明者仍在计算旧任务。若任务域分离和 public input 绑定不严格，系统可能浪费大量算力，甚至把错误批次推进到聚合流程。对跨链系统而言，这类过期证明不会直接盗走资产，但会制造报价延迟、退款等待和用户可见的失败状态。

对 AllSwap 的影响：证明延迟会进入跨链报价模型

AllSwap 这类无托管跨链交换场景里，用户感知到的是“报价、锁定、结算、退款”，但底层路由必须评估不同链和不同结算机制的风险。若某条路径依赖 ZK-Rollup 最终 proof，证明者网络的状态就不只是基础设施细节，而是报价模型的一部分。一个简化的路由评分可以写成：

`routeScore = priceScore + liquidityScore - proofLagPenalty - proverMarketRisk - refundUncertainty`

`proofLagPenalty` 来自当前待证明队列、历史 p95 证明时间、聚合器延迟和目标链验证成本；`proverMarketRisk` 来自证明者集中度、近期 invalid proof 比例、任务重分配频率和是否存在单聚合器；`refundUncertainty` 来自超时后用户资金返回路径是否可验证。AllSwap 不需要把外部证明网络的内部策略暴露给用户，但路由系统应避免把“理论最终性”和“当前可结算状态”混为一谈。

工程上，跨链交换界面和后端状态机可以把证明相关状态拆得更细：`provingQueued` 表示批次已进入证明队列；`proofCommitted` 表示至少有证明者提交了承诺；`proofVerified` 表示目标验证已完成；`aggregationDelayed` 表示子 proof 已足够但根证明未完成；`fallbackRoute` 表示路由选择不再等待该证明路径。这些状态不会让用户学习证明系统细节，却能让失败退款、客服定位和风控日志更可归因。

更重要的是，路由系统不能只看单次 proof 是否成功。它需要观察任务市场的连续信号：待处理任务数量、平均重分配次数、commit 后未 reveal 比例、无效 proof 比例、聚合器选择集中度、同一硬件地域的结果占比，以及 proof 验证后到目标链执行之间的时间差。只有这些指标连续可用，报价引擎才能区分“短时拥塞”和“结构性证明供给不足”。前者可以通过提高等待时间预估或切换低优先级路径处理，后者则应直接降低该路径权重，甚至把用户导向可退款更清晰的替代路线。

这也是 AllSwap 内容体系需要讨论证明者网络的原因。跨链产品不会替外部 Rollup 设计 prover market，但它会消费这些市场给出的结算信号。若证明网络把状态透明化，聚合器日志和验证结果可追溯，跨链路由就可以把 ZK 路径纳入更细的风险分层；若证明网络只提供“最终会证明”的承诺，路由层只能保守估计，把不确定性体现在报价、等待窗口和失败退款逻辑里。用户看到的是一次兑换，系统面对的是多个异步最终性域之间的风险定价。

内链结构上，这篇文章应与 AllSwap 的跨链兑换页、费用页、USDT/USDC 资产页以及前几篇 Rollup/DA/ZK 文章连接。读者从资产兑换进入，能理解为什么不同链的确认体验不一致；从 ZK 研究文章进入，能进一步理解证明市场如何影响跨链路由和失败回滚。

未解决问题：去中心化证明市场仍在早期

第一，证明质量如何定价仍不稳定。最快 proof、最便宜 proof、最分散 proof 和最可审计 proof 不是同一个目标函数。协议必须明确自己优先优化结算速度、抗审查还是长期去中心化。

第二，递归聚合的所有权边界还需要更清晰。子 proof 能被验证，不代表它能被任意聚合器用于领奖；如果所有权规则太弱，中小证明者收益会被压缩；如果规则太强，聚合效率会下降。

第三，跨 Rollup 证明市场可能出现相关性风险。多个 Rollup 若依赖同一批证明者和同一类硬件，市场看似分散，实际会在电力、云服务、GPU 供应或客户端 bug 上同时失效。

第四，硬件公平不能靠口号解决。任务分层、奖励曲线、声誉衰减和罚没参数都可能被大节点反向优化。协议需要公开更多任务级延迟、失败率和集中度指标，而不是只公布总 proof 数。

第五，跨链路由如何消费证明市场信号还没有统一标准。对用户来说，关键不是“某条链使用了 ZK”，而是当前路径的证明延迟、退款确定性和异常可解释性。把这些信号转化成可审计的路由评分，是跨链产品必须补上的工程层。

参考资料

[1] Succinct, Prover Network documentation, https://docs.succinct.xyz/docs/protocol/introduction

[2] Succinct, SP1 zkVM documentation, https://docs.succinct.xyz/docs/sp1/introduction

[3] RISC Zero, zkVM documentation, https://dev.risczero.com/api/zkvm/

[4] RISC Zero, Remote proving and Boundless documentation, https://dev.risczero.com/api/generating-proofs/remote-proving

[5] Ethereum Foundation, Zero-knowledge rollups, https://ethereum.org/en/developers/docs/scaling/zk-rollups/

[6] Scroll, zkEVM and proof generation documentation, https://docs.scroll.io/en/technology/zkevm/intro-to-zkevm/

[7] Mina Protocol, recursive zk-SNARKs and protocol documentation, https://docs.minaprotocol.com/

[8] Aleo, network participants and Proof of Succinct Work overview, https://aleo.org/how-aleo-works/

[9] StarkWare, recursive proving efficiency discussion, https://starkware.co/blog/minutes-to-seconds-efficiency-gains-with-recursive-circuit-proving/

[10] L2BEAT, Scaling summary and risk context, https://l2beat.com/scaling/summary