Discussion - Protocols, Session 2, DeFi Security Summit 2022
三句話摘要
智能合約安全審計中的bug注入測試與風險評估策略 安全審計的成熟在於承認bug注入只能測試基本發現能力，需多維度評分體系與充足延遲窗口共同降低風險，而非追求發現最多或最複雜的漏洞。 Bug注入測試的真實意義——注入的漏洞源自內部代碼審查中實際發現的缺陷（如重入漏洞），代表開發者在正常審查中確實會犯的錯誤，藉此測試審計人員的基本盡職調查能力，而非尋找最複雜的漏洞。
重點整理
重點- 1
Bug注入測試的真實意義——注入的漏洞源自內部代碼審查中實際發現的缺陷（如重入漏洞），代表開發者在正常審查中確實會犯的錯誤，藉此測試審計人員的基本盡職調查能力，而非尋找最複雜的漏洞。
- 2
費米估算法的侷限——使用粗略估算技術統計總bug數，但存在根本問題：無法區分bug嚴重程度，且容易被扭曲（同一bug在多個合約出現可能被算作多個bug），甚至會完全遺漏某一整類問題。
- 3
多維度風險評分體系——基於歷次安全事件的事後分析建立評分標準，涵蓋測試覆蓋率（如80%、90%）、代碼審查、部署準備度等內部可控維度，團隊可根據需求調整優先級，該體系已在Terra事件中被驗證。
- 4
鏈上延遲機制的設計——最少5天的交易延遲，預期每步用時1天（監看+討論+集結簽名），即使「增加延遲本身」也視為關鍵操作，用時間換取發現問題的窗口。
實用技巧與重點
乾貨- 交易最短延遲時間：5天
- 延遲構成預期：監看、討論升級、集結簽名各至少1天
- 評分維度：測試覆蓋率（80%、90%等具體比例）、代碼審查、部署準備度檢查清單
- Bug注入來源：內部代碼審查發現的、本可被捕捉的缺陷
- 報告流程：預備審計報告→披露內部已知bug→最終報告說明重疊
- 評估模式轉變：從全面嚴重程度排名→二元判斷（是否達到基本盡職調查）
- 驗證環境：Terra事件期間被實戰測試
結論
結論“安全審計的成熟在於承認bug注入只能測試基本發現能力，需多維度評分體系與充足延遲窗口共同降低風險，而非追求發現最多或最複雜的漏洞。”
完整解析
詳細智能合約安全審計面臨一個根本性問題：如何評估審計品質本身？傳統方法花費大量時間研究、驗證和同行審查bug，最終撰寫公開報告，流程繁瑣。講者團隊提出了創新思路——故意在代碼中注入bug，以此測試審計人員能否發現這些預先植入的缺陷。
關鍵是這些bug的選擇標準。它們不是隨意的人為錯誤（如風格問題會被lint自動捕捉），而是代碼審查中常見且容易遺漏的真實漏洞，比如重入攻擊。這直接反映開發者在現實審查中確實會犯的問題，因此測試結果更具現實意義。透過這個方法，團隊建立了一個衡量審計實際有效性的指標。
但團隊快速發現這個方法存在深層侷限。他們採用費米估算法粗略估計總bug數——收集各種數據點進行粗略推算。問題在於，bug嚴重程度差異巨大，從小邏輯缺陷到資金損失漏洞天差地別，統計上無法區分。更糟的是，統計極易被扭曲：同一個bug在多個合約上重複出現，可能被算作七個不同的bug，人為提高發現量。最深層的問題是可能完全遺漏某一整類問題——就像只調查一個湖泊的魚，卻沒發現它通過溪流連接到一個巨大的湖泊。
團隊後來調整策略，放棄用bug注入作為複雜的嚴重程度排名工具，改為一個二元檢驗：審計人員是否進行了基本的盡職調查？這更務實也更有用。
在風險評分體系上，經驗來自苦痛。團隊經歷過多個安全事件，進行事後分析（postmortem），逐漸建立評分維度：測試覆蓋率、代碼審查、部署準備度等團隊能控制的內部因素。測試覆蓋率細化為具體比例（80%、90%），策略可根據資源調整優先級，比如「改善測試或尋求代碼審查」。這個系統在Terra崩潰期間經歷實戰驗證並保護了該協議，但仍在持續改進。
在鏈上governance層面，團隊引入了最少5天的交易延遲機制。設計邏輯是給予社區足夠時間發現問題、討論升級或集結簽名者，樂觀情況下每步約1天。值得注意的是，即使看似不重要的操作（如增加延遲本身）也被視為關鍵操作，因為錯誤的參數會導致系統完全無用。這是鏈上治理中「用時間換安全」的經典設計。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
