上一篇的 Slither 輸出有 40 個 Findings，並且說明其中一個是已知攻擊的根因，今天說明 Slither 評估方式與優缺點。

評估指標

要計算這些指標，需要一份已經標記答案的資料集，也要先定義計算單位。相同漏洞被兩個 Detector 回報時，可能算一個，也可能算兩個。定義不同，最後的數字就不能直接比較。

最常用的兩個指標是 Precision 和 Recall：

Precision = TP / (TP + FP)
Recall    = TP / (TP + FN)

Precision 看的是工具回報的結果裡，有多少是真的。Precision 越高，需要排除的誤報越少。Recall 則是看資料集裡的已知問題，有多少被工具找到了。

Accuracy 會把 TP、FP、FN、TN 全部放進去算。如果資料集裡大多數樣本都沒有問題，工具就算把全部樣本都判成「沒有問題」，也可能得到很高的 Accuracy，因此評估時不適合只看這個數字。

Impact 和 Confidence 的意義

Day 4 看過 Finding 裡的 Impact 和 Confidence。這兩個值是在 Detector 類別裡先設定好的，同一個 Detector 掃不同合約時，帶的分級也一樣。

描述這類 Finding 的 Impact 和 Confidence，沒有用這份資料集計算，不能拿來當 Precision 或 Recall。Confidence 也不是統計機率。至於實際損失多少、函式是否可達、合約裡有沒有資產，只能當參考。

Slither 的優點

跑 Slither 不用先準備攻擊交易。分析本地原始碼時也不用連到 RPC，合約能編譯就可以開始掃。拿到陌生專案時，可以先找權限控制、外部呼叫、未初始化變數、危險的轉帳和其他常見結構。

Slither 底層的分析結果也能拿來寫自己的 Detector 或 Printer。官方論文列出的用途包含漏洞偵測、最佳化、理解合約和輔助人工 review。

Slither 的限制

Day 5 已經遇過編譯的問題。實際掃描舊專案時，常常要先處理編譯器版本、import、套件路徑和 build 設定。

Detector 只能依照已實作的分析規則判斷。arbitrary-send-eth 可以追蹤轉帳目的地是不是來自函式參數，也會檢查函式有沒有被保護。但它不知道協議設計上誰應該領錢、某個 epoch 能不能重複領，或 Oracle 的價格在經濟上是否可靠。

明日預告

下一篇會用案例來說明 Slither 的限制。