Zero Knowledge security for beginners — Laurence Kirk | Extropy.io
三句話摘要
零知識證明（ZK）的安全漏洞類型、攻擊原理與開發者需知的核心防禦概念。 ZK 系統的「數學嚴謹性」是雙面刃：它讓證明難以偽造，卻也讓開發者過度信任電路設計，under-constrained circuit 與有限域邊界錯誤才是最實際的敵人，必須在電路層逐一約束、逐一驗範。 1. ZK 安全的核心矛盾：數學嚴謹性反而讓人降低戒心
重點整理
重點- 1
1. ZK 安全的核心矛盾：數學嚴謹性反而讓人降低戒心
- 2
傳統 Solidity 合約人們會仔細審查程式碼，但 ZK 證明因為有「數學嚴格性」的光環，開發者與使用者容易過度信任，在設計上承擔更高風險。這種心態讓 ZK 系統的安全缺陷更難被發現。
- 3
2. Under-constrained circuit 是最普遍的根源漏洞
- 4
電路（circuit）是 ZK 系統中「驗證 Prover 主張」的核心結構，若約束條件不夠嚴格，Prover 可以輸入不正確的值卻仍通過驗證。開發者必須確保電路「精確地」對應 Prover 宣稱的所有條件，不留任何彈性空間。
- 5
3. 有限域運算需要顯式 range check
- 6
ZK 系統建立在有限域數學上，數值有最大上限，超過後會 wrap around。攻擊者可利用此特性構造看似合法但實為異常的輸入值。因此在算術運算前必須加入範圍檢查（range check），確認數值在合法區間內。
- 7
4. 去中心化 rollup 時代將使「真實作弊」威脅浮現
- 8
目前 Layer 2 的 Prover 與 Verifier 合約由同一批人撰寫，信任假設其實是隱性的。當去中心化序列器與 proving market 出現後，陌生第三方將參與產生證明，soundness 的安全假設才會真正被測試。
實用技巧與重點
乾貨- ZK 核心安全屬性：Completeness（正確證明被接受）、Soundness（錯誤證明高概率被拒絕）、Zero-knowledgeness（Verifier 無法反推 secret input）
- 主要攻擊面（依文獻統計）：Circuit 層漏洞佔大多數，其次是 Prover 作弊，Zero-knowledge 洩漏案例最少
- 漏洞類型一覽：
- Under-constrained circuit（約束不足）
- Non-deterministic circuit（非確定性電路，under-constrained 子集）
- Arithmetic overflow / underflow（有限域邊界問題）
- Frozen Heart（Fiat-Shamir 轉換誤用，缺少關鍵資訊）
- Trusted setup 洩漏（multiparty ceremony 共謀或洩漏）
- 編譯器最佳化消除約束（compiler optimization 移除必要 constraint）
- 工具鏈：Circom（低階電路語言，廣泛使用但偏底層）、Noir（Aztec，已抽象 ZK 細節）、Cairo（Starknet，資料型別為雙 2^128 結構）、0js
- Zcash 案例：論文中存在錯誤，若 trusted setup 洩漏可憑空製造代幣，事後已修補
- Scroll 參考資源：提供詳細電路文件，展示 EVM 電路如何拆解為 storage、hash（Merkle-Patricia tree）等子電路
- 電路規模：現代 ZK 系統電路達數百萬 gates，以巨型表格（row = constraint）表示
結論
結論“ZK 系統的「數學嚴謹性」是雙面刃：它讓證明難以偽造，卻也讓開發者過度信任電路設計，under-constrained circuit 與有限域邊界錯誤才是最實際的敵人，必須在電路層逐一約束、逐一驗範。”
完整解析
詳細這場演講的背景是 ZK（零知識證明）技術正快速從學術密碼學走向工程實踐，越來越多開發者開始撰寫 Cairo 合約、Noir 電路、Aztec 應用，但他們對 ZK 底層數學的理解普遍不足。講者認為這構成了一個系統性安全風險：目前整個社群高度依賴少數密碼學專家做安全審計，而 ZK 系統上有大量 TVL，一旦出現漏洞損失難以挽回。
ZK 系統的運作模型是「Prover（證明者）」向「Verifier（驗證者）」提出主張，例如「這筆交易被正確執行了」，並提交一份數學證明。Verifier 不必信任 Prover，只需驗證這份證明即可。兩個核心安全性質是：Completeness（合法的正確證明一定被接受）與 Soundness（錯誤的假證明幾乎一定被拒絕）。現代系統透過 Fiat-Shamir 啟發式方法將互動式協議壓縮成非互動式（NIZK），才能用於區塊鏈環境。
然而講者指出一個反直覺的心理陷阱：正因為 ZK 帶有「嚴格數學證明」的光環，開發者與使用者反而容易過度信任、降低風險意識。這一點在目前的 Layer 2 rollup 架構中尤為明顯——Prover 系統與 Verifier 合約往往由同一團隊撰寫，信任是隱性存在的。但當 proving market 成熟、第三方開始競爭產生證明時，soundness 才會真正受到敵對環境的考驗。
在具體漏洞類型上，講者聚焦三大類：第一是 under-constrained circuit，即電路對 Prover 的輸入約束不夠嚴格，讓攻擊者可以提交不正確的 witness 卻仍通過驗證——這是最普遍的問題，且在 Circom 與高階語言（Cairo、Noir）中都會出現。第二是有限域的算術邊界問題，ZK 系統在模數有限域上運算，若沒有顯式 range check，數值 overflow 後 wrap around 可能使本應失敗的驗證通過。第三是 Fiat-Shamir 轉換的誤用（稱為 Frozen Heart 漏洞）：將互動式協議壓縮為非互動式時，若未將足夠資訊納入雜湊計算，就等同於留下了「under-constrained」的缺口。此外，部分 SNARK 需要 trusted setup（共同參考字串），若多方計算儀式中有參與者串謀洩漏秘密值，攻擊者即可偽造任意有效證明，Zcash 早年的文件錯誤就是此類風險的典型。
講者最後強調，目前業界的安全工具雖然已存在，但仍處於早期階段，覆蓋範圍有限。更根本的解法是教育普及與更好的語言抽象——像 Noir 已試圖將 ZK 細節從開發者視野中隱藏，但資料型別限制、迴圈表達、分支等底層有限域特性仍會在各語言中不同程度地「浮現」，這是開發者無法完全迴避的知識門檻。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
