Secure development of smart contract systems | Elliot Friedman (Solidity Labs) - DSS 101 2024
三句話摘要
智能合約安全開發的完整策略：從測試工具堆棧到常見盲點，以及如何用自動化框架防止治理提案漏洞。 智能合約安全不在於單一完美的測試方法，而在於分層的、從低成本測試開始的體系化方法，同時特別留意容易被忽視的治理提案和部署腳本，用自動化工具確保參數和狀態轉移的正確性。 智能合約系統的分類決定安全需求
重點整理
重點- 1
智能合約系統的分類決定安全需求
- 2
不同類型的智能合約需要不同的治理和安全投入。不可變系統（如 Uniswap 無費用開關）幾乎無需治理；最小化治理系統允許調整特定參數但無升級能力；高度治理依賴系統（如借貸市場和 Rollup）包含大量參數和可升級合約，參數設置不當會導致資金重大損失。
- 3
開發者的注意力分配導致盲點
- 4
漏洞最容易在開發者忽視的地方隱藏。當開發者聚焦複雜的數學運算或關鍵邏輯時，部署腳本和治理提案中的簡單錯誤會被忽視。這類盲點不是因為難度高，而是因為注意力在別處。
- 5
安全堆棧應從低成本方法開始逐步升級
- 6
單元測試、集成測試、模糊測試是最經濟的漏洞發現方式；符號測試和形式化驗證成本更高但能捕捉特定邏輯錯誤；代碼審查、審計和漏洞賞金則是更昂貴的防線。應優先構建強大的測試套件，再逐步採用高級技術。
- 7
治理提案和部署腳本需與合約代碼同等嚴謹的測試
- 8
治理提案可能涉及合約升級、參數調整等關鍵操作，但常缺乏測試。儲存布局變更、地址連接錯誤、參數設置不當等問題往往在上線時才發現。應將治理提案視為代碼的一部分進行完整的集成測試。
實用技巧與重點
乾貨- 安全堆棧的工具與方法
- 靜態分析、單元測試、集成測試、模糊測試
- 符號測試：Halmos、HVM
- 形式化驗證：Sor Approver、KEVM、Contour
- 代碼審查、外部審計、漏洞賞金
- 三種智能合約系統類型
- 不可變型：無管理員密鑰、無升級能力（如 Uniswap Factory）
- 最小化治理型：允許調整特定參數但無升級（如 Uniswap 費用開關、Morpho、Euler）
- 高度治理依賴型：可升級、參數眾多（如借貸市場、Rollup）
- Forge 提案模擬器功能
- 標準接口：允許用 Solidity 編寫治理提案而非 JSON
- 地址類型系統：自動進行類型檢查，防止地址連接錯誤
- 狀態差異分析：顯示提案執行後的所有狀態變更
- 提案追蹤：比較鏈上實際提案與本地預期提案
- 驗證功能：檢查提案後系統不變性是否仍然成立
- Vault 合約練習案例中發現的常見漏洞
- Vault 0：缺少小數位數歸一化，導致不同精度代幣無法正確計算
- Vault 1：移除代幣後未更新驗證函數，導致集成測試未捕捉差異
- Vault 3：部署腳本設置與驗證函數不匹配，未在測試中運行驗證
- Vault 4：升級後儲存槽位錯位，導致授權映射失效
結論
結論“智能合約安全不在於單一完美的測試方法，而在於分層的、從低成本測試開始的體系化方法，同時特別留意容易被忽視的治理提案和部署腳本，用自動化工具確保參數和狀態轉移的正確性。”
完整解析
詳細Elliot Fredman 從智能合約的基本分類開始，強調不同系統類型需要不同的安全策略。不可變系統如 Uniswap 的核心 AMM 合約幾乎無需治理工具，因為沒有可改變的參數；最小化治理系統允許調整費用等特定參數，但整體結構不可升級；而借貸市場和 Rollup 等高度治理依賴系統則包含大量需要精心配置的參數，這類系統的參數設置不當可能導致龐大資金損失。
講者指出開發者的一個普遍問題：當聚焦於系統的複雜部分時，簡單錯誤會成為盲點。假設開發者在編寫 AMM 時花費所有時間確保數學計算無誤，反而會忽視更簡單但同樣致命的邏輯錯誤。這就像在昏暗房間裡用手電筒照一處，其他地方就變成了黑暗。
安全堆棧的核心概念是成本效益最優化。單元測試、集成測試和模糊測試是最經濟的方式，應該首先投入資源建立強大的測試套件。若仍無法發現問題，才升級至符號測試、形式化驗證等成本更高的方法。代碼審查則像進行橡皮鴨偵錯，逐行檢視每段代碼的邏輯、假設和影響。最後是外部審計和漏洞賞金，它們最昂貴但也最有效。講者強調，最差的情況是黑帽駭客先發現漏洞，這正是投資安全的必要性所在。
後半段以 Forge 提案模擬器為例，說明如何系統地測試治理提案。傳統上治理提案以 JSON 格式定義目標、呼叫數據和值；而 Forge 提案模擬器允許用 Solidity 本身編寫提案，自動追蹤所有呼叫並轉換為系統理解的格式。搭配地址類型系統，開發者可防止誤連接合約的錯誤。更重要的是，提案可透過狀態差異分析顯示執行前後的所有變更，並驗證系統不變性在提案後是否仍然成立。
四個遞進的 Vault 合約練習揭示真實開發中的常見陷阱。Vault 0 缺少小數位數歸一化，使得 USDC（6 位）和 USDT（8 位）無法正確交互。Vault 1 在移除代幣時忘記更新驗證函數，集成測試沒有捕捉到這個差異。Vault 3 引入可升級合約，但部署腳本與驗證邏輯不匹配，導致上線後才發現授權列表缺失。Vault 4 升級時儲存槽位順序改變，使得原有代幣的授權映射失效。這些案例的共通點是：測試覆蓋率不足或未正確運行驗證，導致簡單但致命的錯誤漏過。
講者最後強調應該將大部分開發時間用於測試，而非編寫合約。關鍵是向自己證明系統確實按預期運作，並深思所有邊界情況。要達到這一點，應將合約視為有限狀態機，識別系統的所有可能狀態和狀態轉移，並在測試框架中表達不變性關係。隨著行業愈發關注模糊測試和形式化方法，注意力容易集中在複雜邏輯而忽視治理方案，這正是該工具的價值所在。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
