Crypto Sentry: Threat Modelling Web3 Infrastructures — Rahul Saxena | zkSync
三句話摘要
ZKSync 協議安全工程師分享內部安全團隊的實際職責，以及在複雜 ZK 工程系統中面臨的六大安全挑戰。 --- 內部安全團隊的核心價值在於「全系統視角」——這是外部審計員、各自為政的開發團隊、以及任何單一角色都無法單獨提供的東西。 1. 內部安全團隊的真實工作遠超「找漏洞」
重點整理
重點- 1
1. 內部安全團隊的真實工作遠超「找漏洞」
- 2
安全工程師的職責包含威脅建模、安全導向設計審查、推動開發者文化改變，以及充當不同工程團隊之間的技術橋梁，這些都是外部審計員無法替代的持續性工作。
- 3
2. 測試品質問題根源在於「寫程式的人自己測程式」
- 4
100% 程式碼行覆蓋率指標容易被操縱，無法反映真實安全性；同一個人的盲點會同時存在於程式碼和測試用例中，Web 2 業界已用 QA/SDE 崗位解決這問題，但 Web 3 尚未成熟到這個程度。
- 5
3. Type 4 ZK EVM 的戰略取捨帶來生態工具相容性代價
- 6
ZKSync 選擇 Type 4 路線，優先實現密碼學效能最優化，代價是與 Foundry、Remix 等主流工具的相容性滯後，且自研 Bujam 系統縮減了能審計其程式碼的人才池，因此需要主動承擔知識傳播責任。
- 7
4. 「10 倍工程師困境」是規模化後的安全阻力
- 8
早期明星工程師在組織內累積了半神地位，導致後期難以推動安全規範的落地；安全工程師實際上必須同時是談判者和政治斡旋者，才能讓最簡單的安全變更得以執行。
- 9
--
實用技巧與重點
乾貨- 系統架構數字與技術名稱
- 生成並聚合 ZK 證明耗時約 1 小時
- ZKSync 是 Type 4 ZK AVM（非 Type 1）
- 自研證明系統：Bujam（非通用 Circom/Groth16/PLONK/Halo）
- VM 以 Rust 實作 EVM 模擬電路行為（電路外實作）
- 電路以 Bujam 語言撰寫
- ZK EVM 類型定義
- Type 1：直接對 EVM 原生 opcode 生成 ZK 證明，最貼近 EVM 生態
- Type 4：先將 opcode 轉換為密碼學最優格式再證明，效能最高但工具相容性最差
- 轉換步驟越少 → 越接近 Type 1；轉換越多 → 類型數字越高
- 內部安全團隊具體職責清單
- 威脅建模（Threat Modeling）
- 安全導向設計審查（Security-focused Design Review）
- 持續性 PR 安全審查
- 安全導向程式碼審查
- 安全倡導（Security Advocacy）
- 嵌入式安全工程（Embedded Security Engineering）
- 可信安全元件開發（Trusted Security Component Development）
- 為系統生成不變式（Invariants）
- 撰寫安全規格與設計安全測試
- 組織架構
- ZKSync 包含：密碼學團隊、編譯器團隊、協議團隊、VM 團隊等多個孤立組織
- 與 CYHM 簽署大型教育計畫，普及 Bujam 知識
- Bootloader 測試複雜度來源
- 需同時模擬：電路、L1 合約、L2 智能合約、系統合約、自定義 VM（非 EVM）、共識層
- 各模擬值必須彼此依賴（例如：電路值為 X，則 L1 合約值不能獨立為 Y，必須是 X 的函數）
- --
結論
結論“內部安全團隊的核心價值在於「全系統視角」——這是外部審計員、各自為政的開發團隊、以及任何單一角色都無法單獨提供的東西。”
完整解析
詳細ZKSync 協議安全工程師 Rahul Tua 在本場演講中，回答了業界常見的疑問：既然有外部審計員和漏洞賞金計畫，為什麼還需要一個內部安全團隊？他的答案是，內部安全團隊的工作本質上是一種持續性、全系統視角的工程安全維運，而非一次性的漏洞發現活動。
演講首先釐清了測試文化的根本問題。以 100% 程式碼覆蓋率作為安全指標是危險的，因為這個數字很容易被操縱：只要每行都被呼叫過就算達標，不代表實際行為被驗證過。更深層的問題在於，同一個人寫程式和寫測試，其認知盲點會同步帶入測試案例中。Web 2 業界早已意識到這點，因此設立了 QA 與 SDE（專職測試的軟體開發工程師）崗位。Web 3 生態目前尚未走到這個成熟度，測試品質的缺口只能由安全團隊介入填補。以 ZKSync 的 Bootloader 為例，它同時與電路、L1/L2 合約、自定義 VM 及共識層互動，測試時必須精確模擬各層之間具有依賴關係的數值，這已遠超「單元測試」的範疇，是系統整合測試的極限挑戰。
其次，演講深入解析了 ZKSync 的技術架構選擇與其連帶的安全生態問題。ZKSync 是 Type 4 ZK AVM，在約三年前 ZK EVM 尚未被驗證可行時，選擇優先攻克密碼學效能最優化，以自研的 Bujam 證明系統取代業界通用的 Circom/Groth16，換取電路性能的根本性突破，並將 EVM 相容性問題留待後期解決。這個決策帶來了明顯的生態代價：Foundry、Remix 等主流工具整合滯後，能讀懂 Bujam 系統的安全研究員極少。為此，ZKSync 與 CYHM 合作推動教育計畫，因為只有自己才有能力向外界傳播這套知識。此外，系統由不同語言實作的多個層組成——Rust 寫的 VM 模擬電路行為，Bujam 寫的電路本身——兩者之間的差異不是 bug，而是系統特性，但漏洞賞金提交者往往因缺乏這層上下文而誤報，因此安全團隊需要具備全系統視角來正確分級每一筆提交。
最後，演講談到了組織層面的挑戰，這些往往比技術挑戰更難處理。工程決策在孤立的團隊之間做出，編譯器的一個優化可能對 VM 造成大量連鎖修改，而兩邊工程師之間難以直接溝通這種影響——安全團隊的角色因此像一座技術橋梁，在各組之間傳遞影響鏈資訊。「10 倍工程師困境」則是另一個現實：早期推動公司快速成長的明星工程師，在組織成熟後容易成為安全規範推行的阻力，安全工程師必須同時具備技術能力與政治智慧，才能真正讓安全策略落地。完全遠端的工作環境更讓 Web 2.0 端點安全管控成為幾乎無解的難題：你不知道員工的筆電連接了什麼設備、誰有物理存取權，而加密圈文化又對任何監控有強烈排斥。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
