Can Code be Trusted?, Kurt Barry - DeFi Security 101 2023

Kurt Barry從「代碼能否被信任」這個哲學問題開場，揭示加密貨幣整個範式建立在「信任代碼而非人」的基礎上。他援引Unix之父Ken Thompson的經典論文《Reflections on Trusting Trust》，說明編譯器可以被植入不可偵測的後門：攻擊者在編譯器中嵌入兩個條件分支——一個在編譯特定目標程式時植入後門，另一個在編譯編譯器本身時植入後門邏輯。由於程式可以輸出自己，這個惡意編譯器即使編譯清潔的源代碼也會產生有後門的二進制文件。雖然這看似遙遠，但講者指出Go編譯器本身用Go寫，Go Ethereum是最常見的執行環境，理論上可能受此攻擊。然而，實踐中存在多層防禦：編譯器供應鏈攻擊在開源環保中很難執行、多個客戶端實現用不同語言寫（如Rust、TypeScript等）提供冗餘、符號執行和模糊測試可驗證行為、社會層面的追究成本極高。

講者強調DeFi開發的根本挑戰不在於這些理論威脅，而在於開發者心態轉變的缺失。許多開發者來自Web服務背景，習慣於快速迭代——發現bug、修復、上線新版本。但DeFi代碼部署後通常完全不可改或改變困難，一次駭客攻擊就能導致不可逆轉的多億美元損失。因此需要將「風險永遠不為零但可以降低」的心態內化，同時理解代碼的每一處依賴都是潛在風險點。

為了結構化這個挑戰，講者提出一個金字塔模型，從下到上分別是哲學、流程、測試、驗證、運營。金字塔的設計是刻意的——底層看似不如形式化驗證或審計那樣「高深」，但實際決定了整個系統的穩健性。Philosophy層強調開發者要知道自己的權衡、建立明確的威脅模型（如智能合約開發者可能認為編譯器安全由其他層保證）、採用安全優先而非單純安全的心態（因為代碼bug也會鎖定資金，不一定需要惡意攻擊）。每個項目至少要有一人專責安全，即使是創始人也要擔負這責任。

Process層包括先寫規格說明再實現、嚴格的代碼審查（Maker採用兩人簽核原則）、使用檢查清單（儘管看起來乏味）、事故發生後的分析與流程改進、邀請內外部人員做紅隊測試、分階段推出（如從10萬美元TVL逐步增至最大值）。Testing層要求完整的單元測試覆蓋（必須列舉所有代碼路徑），對已部署合約的集成測試（RPC測試），定義系統級屬性而非僅測試單一函數、模糊測試特別是針對數學例程、代碼變異測試確保測試實際有效（即故意改改代碼，測試應該失敗）。

Verification層是代碼基本完成後的驗證工作，包括形式化驗證（尤其適合需要特定輸入才觸發的bug）、經濟建模做數值模擬、測試網部署、審計或評估。這裡講者刻意改用「評估」而非「審計」術語，因為審計在財務語境有嚴格定義且提供保證，而代碼評估更多是定性判斷。審計往往被新項目高估——如果代碼質量已經很高（前面層次都做好了），往往只需一到兩次審計，除非系統極度複雜。Operations層涵蓋部署後的風險管理：Bug Bounty計畫激勵人們報告漏洞而非利用漏洞、實時監控系統、參數設置的控制流程、充分文檔、對執行環境變化的應對（如gas schedule改動導致硬編碼gas限額失效）、事件響應計畫、演練與模擬。

講者最後以一個反模式作為bonus：許多項目使用原始ETH而不是Wrapped ETH。這在安全性上更差——沒有Reentrancy風險的包裝器、統一為ERC20減少代碼路徑因而減少bug隱藏點、提高和其他協議的互操作性。雖然有gas成本開銷，但安全和可組性收益對大多數應用而言更值。問答環節補充了變異測試工具（Gambit、Sumo等）、升級策略的多樣性、生成代碼（如ZK電路）的信任問題——此時需要對生成工具本身投入審計級別的努力，包括數學驗證、龐大測試套件、甚至形式化驗證。