Demystifying MPC for coSNARKs: How to Collaboratively Prove Sumthing - DeFi Security Summit 2025
三句話摘要
從零開始拆解 Co-SNARK：用 Sum-Check 協議搭配安全多方計算（MPC），實現在不洩露 witness 的前提下將 ZK 證明生成外包給多個節點。 Co-SNARK 的本質是：用加法 secret sharing 把 witness 碎片化、以 Beaver Triple 解決乘法、再套上 Sum-Check 的輪式互動，讓多個不信任的 MPC 節點在不知道秘密的前提下，共同算出一個對 verifier 完全透明的 ZK 證明。 Sum-Check 協議是 ZK 計算正確性的核心積木。 Prover 對多項式在布林超立方體上的求和聲稱一個值 T，verifier 透過 n 輪互動逐步縮減維度，每輪用隨機挑戰值 r 固定一個變數，最終以一次多項式直接查詢驗証結果。整個過程將 verifier 複雜度從 2ⁿ 壓縮到 O(n)。
重點整理
重點- 1
Sum-Check 協議是 ZK 計算正確性的核心積木。 Prover 對多項式在布林超立方體上的求和聲稱一個值 T，verifier 透過 n 輪互動逐步縮減維度，每輪用隨機挑戰值 r 固定一個變數，最終以一次多項式直接查詢驗証結果。整個過程將 verifier 複雜度從 2ⁿ 壓縮到 O(n)。
- 2
Schwartz-Zippel 引理是 Sum-Check 安全性的數學基礎。 非零多項式在隨機點為零的機率至多為 d/|F|，因此只需對隨機點做一次查詢，即可高概率判定兩個多項式是否相等，這是每一輪檢查的安全保證。
- 3
加法運算對 secret sharing 天然線性，乘法需要 Beaver Triple。 加法與公開常數乘法可讓每個節點在本地計算自己的 share 而無需溝通；但兩個秘密值相乘時，節點需交換輔助資訊（e = x−r, f = y−s），再利用預先分發的 Beaver Triple (r, s, t=r×s) 完成乘法，且過程不洩露任何關於 x、y 的資訊。
- 4
現有玩具協議仍缺少多個關鍵 ZK-SNARK 元件。 目前僅達到「計算正確性」而非「知識論證」；節點在重建多項式時仍會學到 a×w、b×w 等乘積，洩露資訊；此外缺少 arithmetization、commitment、blinding 等組件，才能組成完整的 ZK-SNARK。
實用技巧與重點
乾貨- ZK-SNARK 全名：Zero-Knowledge Succinct Non-Interactive Argument of Knowledge
- Co-SNARK 提出時間：2021 年，作者 Osmir Bonet
- 生產案例：Tacio（使用 MPC 節點讓手機外包 ZK 證明）
- Sum-Check 複雜度：Prover O(2ⁿ)、Verifier O(n)、Proof size O(n·d)
- Soundness 錯誤率：n·d / |F|（對大域如 2¹²⁸ 可忽略）
- 乘法 MPC 通訊量：每次乘法需 O(m) 輪節點間通訊（m = 節點數）
- Beaver Triple 結構：(r, s, t) 其中 r, s 均勻隨機，t = r × s
- Secret sharing 方案：m-of-m 加法分拆（需全部 share 才能重建）
- 非互動化方式：用 Fiat-Shamir 轉換，以 hash(transcript) 替代隨機挑戰 r
- Semi-honest 假設：節點遵守協議但可從 transcript 推斷資訊（仍是限制）
- MPC 敏感點：電路中乘法閘越多，通訊開銷越高
- ZK Roll-up 應用：將多筆 L2 交易打包成一個 succinct proof 發上鏈，節省 gas
結論
結論“Co-SNARK 的本質是：用加法 secret sharing 把 witness 碎片化、以 Beaver Triple 解決乘法、再套上 Sum-Check 的輪式互動，讓多個不信任的 MPC 節點在不知道秘密的前提下，共同算出一個對 verifier 完全透明的 ZK 證明。”
完整解析
詳細ZK-SNARK 的核心問題是：prover 端的計算非常昂貴，尤其是記憶體與時間消耗。對於手機這類資源受限的裝置，若要讓它產出 ZK 證明幾乎不可行，合理做法是把計算外包給雲端——但 witness（私密輸入）絕對不能洩露。Co-SNARK 在 2021 年提出的解法是：把 proving 外包給一個由 MPC 節點組成的網路，每個節點只持有 witness 的一小片 share，節點間合作完成計算後，拼出完整 proof 送給 verifier，而 verifier 完全看不出這個 proof 是一人產出還是多節點共同生成。
要理解 Co-SNARK 如何運作，必須先理解 Sum-Check 協議。Sum-Check 解決的問題是：已知多項式 f，如何證明它在所有布林超立方體（0/1 的 n 元組）上的求和等於某個值 T，而不讓 verifier 自己跑完指數量的評估？方法是 n 輪互動：每輪 prover 傳送一個單變數多項式 Pᵢ（讓第 i 個變數自由，其餘已固定為前幾輪的隨機挑戰），verifier 驗証 Pᵢ(0)+Pᵢ(1) 是否吻合上一輪的值，然後隨機抽一個點 rᵢ 送回。每一輪等於把超立方體的維度降一，直到最後一輪 verifier 直接查詢原始多項式以完成最終核對。整個安全性依賴 Schwartz-Zippel 引理：非零多項式在隨機點為零的機率極低（d/|F|），因此每輪的「多項式是否相等」檢查都以極高機率正確——n 輪累積誤差仍為 n·d/|F|，對大型有限域而言可忽略。
把 Sum-Check 搬到 MPC 環境，關鍵挑戰在於多項式的係數（含 witness w）必須被秘密分享。加法運算天然地支持線性分拆：節點只需把自己那份 share 相加，結果就是總和的 share，完全不需要溝通。乘法則截然不同——兩個 share 直接相乘不等於積的 share。這裡的解法是 Beaver Triple：在協議開始前的離線階段，為每個乘法閘預先生成並分發 (r, s, r×s) 的隨機 triple shares。實際計算時，每個節點本地計算 e_i = x_i − r_i 與 f_i = y_i − s_i，然後廣播這兩個值；由於 r、s 完全隨機，廣播不洩露 x 或 y 的任何資訊。所有節點收齊廣播後，各自用 t_i + e·s_i + f·r_i + e·f/m 計算自己的 z_i，最終所有 z_i 的總和即等於 x×y。這個迂迴的方式把乘法化為線性操作加上一輪通訊，是 MPC 中處理乘法的標準手段。
有了這兩個工具，Co-SNARK 的流程就清晰了：prover 將 witness 以加法 secret sharing 分發給 m 個 MPC 節點，同時分發對應每個乘法閘的 Beaver Triple shares；每個節點在本地計算自己那份 T 的 share，重建後公開 T；接著按 Sum-Check 的輪次，每個節點計算自己對 Pᵢ 多項式的貢獻 share，節點間交換後重建完整 Pᵢ；挑戰值 r 用 hash(transcript) 非互動地生成，確保每個節點算出相同的 r；最後重建最終查詢結果完成核對。目前這個玩具協議仍有缺口：重建多項式時節點會學到 a×w 等乘積值，不達零知識標準；缺少 arithmetization（將任意電路轉為多項式約束）、commitment scheme、blinding 等元件，加上這些才能組成完整 ZK-SNARK。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
