如何審計智能合約？ （安全基礎知識）

了解智能合約漏洞

1. 當惡意合約在狀態變更完成之前反覆回呼易受攻擊的合約時，就會發生重入攻擊，從而意外耗盡資金。

2. 當算術運算超過 uint256 的最大值或最小值時，會發生整數上溢和下溢，導致不正確的平衡或邏輯旁路。

3. 如果傳回值未經驗證，未經檢查的外部呼叫可能會導致靜默失敗，從而允許執行在傳輸或函數呼叫失敗的情況下繼續進行。

4. 不當的存取控制使未經授權的使用者能夠呼叫特權功能，例如僅限所有者的升級或代幣鑄造。

5. 當關鍵狀態轉換依賴可預測的交易順序時，搶先交易就成為可能，從而暴露了拍賣或閃電貸套利等敏感操作。

靜態分析工具及其作用

1. Slither 無需執行合約即可分析 Solidity 原始碼中的常見反模式和漏洞，從而提供快速且可擴展的檢測。

2. MythX 與 IDE 和 CI/CD 管道集成，以執行符號執行和基於模糊測試的分析，識別更深層的邏輯缺陷。

3. Solhint 透過標記不一致的可見性說明符、缺少 require 語句和不安全的低階呼叫來強制執行編碼標準和最佳實務。

4. Crytic 的 Echidna 使用以 Solidity 編寫的自訂斷言進行基於屬性的測試，驗證數千個產生輸入的不變量。

5.並行使用多個靜態分析器可以顯著增加覆蓋範圍－沒有一個工具可以捕捉所有類別的錯誤。

手動程式碼審查要點

1. 追蹤所有外部呼叫並驗證它們是否發生在狀態更新之後，特別是在提現或轉帳功能中。

2. 確認所有使用者提供的輸入在影響儲存或發出事件之前都經過 require 或 revert 語句。

3. 檢查回退和接收函數是否有意外行為，特別是在處理 ETH 傳輸以及複雜邏輯時。

4. 檢查硬編碼地址、幻數或未版本化的庫鏈接，這些鏈接可能會影響再現性或引入隱藏的依賴項。

5.每個修飾符都必須經過可重入安全性、副作用以及與其他修飾符的可組合性審核。

單元檢查以外的測試方法

1. 整合測試模擬多個已部署合約之間的交互，以暴露介面不匹配和意外的 Gas 消耗模式。

2. 模糊測試將隨機輸入註入公共函數，以觸發單元測試經常遺漏的邊緣情況行為。

3. 基於屬性的測試定義了高級不變量，例如“總供應量永遠不會減少”或“餘額不能為負”，並在不同的場景中驗證它們。

4.像Sepolia和Arbitrum Goerli這樣的測試網提供了真實的環境，可以觀察現實世界的氣體動態和網路擁塞。

5. 必須在模擬區塊時間戳記操作下測試與時間相關的邏輯，以確保延遲或未來調度期間的正確性。

常見問題解答

Q：我可以只依靠自動化工具進行智慧合約審計嗎？答：不能。自動化工具可以偵測已知的模式，但無法評估業務邏輯的正確性、經濟誘因或需要人類直覺和領域知識的新穎攻擊向量。

Q：在零知識證明合約的背景下，「可信設定」意味著什麼？ A：指初始產生zk-SNARK驗證所需的密碼參數；如果受到損害，它就會破壞健全性保證並允許偽造的證明通過驗證。

Q：為什麼我應該避免使用 tx.origin 進行授權檢查？答：因為 tx.origin 傳回啟動交易鏈的原始 EOA，因此很容易透過中間合約進行網路釣魚，這些合約在保留原點的同時轉送呼叫。

Q：委託呼叫漏洞與常規呼叫漏洞有何不同？答：Delegatecall 在呼叫合約的上下文中執行程式碼，這表示目標中的儲存佈局不符或未初始化的變數可能會直接破壞呼叫者的狀態。