去中心化 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