Clear as Mud, Gonçalo Sa - DeFi Security Summit 2022
三句話摘要
Gonzalo Skateboard 分享開發 DeFi 協議時最常見的四個致命錯誤，以及為什麼它們會危害協議安全性。 協議安全的最大敵人不是複雜的攻擊，而是開發者為了看起來安全而做出的選擇。 可讀性決定可審計性：調用圖複雜到無法在任何螢幕上完整顯示的代碼，是審計人員的噩夢。Diamond Standard 等標準好心卻導致代碼過度碎片化，實際上降低了安全性。
重點整理
重點- 1
可讀性決定可審計性：調用圖複雜到無法在任何螢幕上完整顯示的代碼，是審計人員的噩夢。Diamond Standard 等標準好心卻導致代碼過度碎片化，實際上降低了安全性。
- 2
不可變優於可升級：不要假設你需要升級功能。Uniswap 因為完全不可升級而被讚揚，VCV 則因為保留了權限函數導致私鑰被盜。用版本控制管理不同合約版本，風險更低。
- 3
安全工具應該全部組合使用：靜態分析、形式驗證、審計、變異測試，每一個工具都有其時間和地點。Maker 是正面案例，充分利用了形式驗證。不應該因為選擇了某個工具就放棄其他工具。
- 4
過度防禦等同於代碼污染：nonReentrant 修飾符被濫用到隨處可見。並不是所有函數都需要防重入，有時重入本身不是問題。Thorn 平台被批評時，多數批評根本不是真正的漏洞。
實用技巧與重點
乾貨- Diamond Standard：協議升級標準，但導致代碼碎片化且難以審計
- Uniswap：完全不可升級的協議，因此更安全
- VCV：反面案例，因保留權限函數而遭私鑰盜竊
- Maker：正面案例，正確運用形式驗證
- 安全工具列表：
- 靜態分析（Static Analysis）
- 形式驗證（Formal Verification）
- 審計（Audit）
- 變異測試（Mutation Testing）
- nonReentrant 修飾符：被過度使用，導致代碼膨脹
- Thorn 平台：講者提及被評論者誤認為有重入與可鍛性漏洞，但實際上並非漏洞
- 2020 年 GitHub 討論：關於 Diamond Standard 升級功能的爭論
結論
結論“協議安全的最大敵人不是複雜的攻擊，而是開發者為了看起來安全而做出的選擇。”
完整解析
詳細DeFi 開發面臨一個根本性的矛盾：開發者想要創新、想要用更複雜的架構加速開發，但過度的複雜性反而自我毀滅。Gonzalo 的談話核心在於四個具體的反面教材。
第一個問題是代碼可讀性。許多協議開發者追求高度模組化，把代碼分散到無數個小檔案，每個檔案只有一個定義和一個介面。這看似井井有條，但當審計人員打開你的項目時，他們面對的是一個龐大到無法在任何螢幕上顯示的調用圖。Diamond Standard 這類協議升級標準初心是好的，但實踐中導致代碼過度碎片化。講者強調：不可讀的代碼就是不可審計的代碼，不可審計的代碼就更容易被破解。這不是形容詞，是邏輯推論。
第二個問題是不必要的升級功能。講者稱之為「在代碼裡留後門」。2020 年的 GitHub 討論中，有人辯稱 Diamond 可以移除升級功能，但為什麼一開始就要加上呢？Uniswap 之所以被讚揚，正是因為它完全不可升級。如果需要新版本，用戶可以在前端選擇不同版本，但智慧合約本身永遠不變。VCV 是反面教材：它保留了權限函數，最終導致私鑰被盜。不可變的合約被部署後，如果沒有被攻擊，其被破解的風險隨時間遞減。
第三個誤區是在安全工具之間選邊站。開發者常說「我用了形式驗證，所以不需要靜態分析」或「我要審計，所以不需要變異測試」。這是錯誤的。靜態分析、形式驗證、審計、變異測試（像 Echidna 的變異工具），這些全部應該組合使用。Maker 是正面案例，正確地運用了形式驗證。講者的觀點是：不管你現在處於哪個融資階段，這些工具最終都會用上，乾脆全部用。
最後一個問題是過度防禦。nonReentrant 修飾符幾乎成了 DeFi 代碼的標配，但並非每個函數都需要它。重入本身有時不是問題。Thorn 平台的批評者們指責其代碼有重入和可鍛性問題，但講者指出這些根本不是實際的漏洞。代碼被不必要的防禦措施污染，結果反而降低了代碼品質和可讀性。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
