---
title: "如何閱讀智慧合約稽核報告"
description: "智慧合約稽核是對指定程式碼、建置、部署、假設與性質所做的有限審查；其發現與修正必須和正式環境逐項核對。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 如何閱讀智慧合約稽核報告

> 僅供教育參考，不構成投資或資安建議。稽核報告、工具結果、已修正的發現或相符的原始程式檔，都不是認證、保險、賠償承諾，也無法證明正式環境的部署安全。

<a id="answer"></a>

## 直接答案

智慧合約稽核是在明定期間內，對指定需求、原始程式碼、建置輸入、部署邏輯與安全假設所做的有限審查。稽核人員運用互補方法識別缺失、展示可利用路徑、評估影響並檢查建議修正。結論只適用於報告載明的稽核快照與證據。

快照應鎖定程式碼儲存庫與提交或目錄樹雜湊、子模組與相依套件鎖定檔、編譯器及設定、產生的程式碼、部署腳本、目標鏈與位址、代理、實作或信標、建構函式或初始化函式資料、程式庫、管理員、時間鎖，以及某一區塊或時間點。明確的排除項目與納入項目同樣重要：前端、keeper、預言機、跨鏈橋、治理流程或鏈下簽署者即使不在稽核範圍內，也可能主導風險。

稽核需要威脅模型與規格。應識別資產、參與者、特權角色、信任邊界、攻擊者能力、排序與重組假設、外部相依項目、狀態轉換，以及精確的安全性與活性性質。缺少單位、前提條件、量詞與例外的不變量，可能完美地證明或測試錯誤行為。

應維護四本帳：範圍、建置與部署身分帳；需求、威脅與不變量帳；發現、證據與複測帳；殘餘風險、接受與揭露帳。報告沒有 `critical` 發現不等於資安認證，標示為 `resolved` 的發現未必已部署，而證明也只涵蓋其編碼的性質、模型與假設。

<a id="mechanism"></a>

## 運作方式

人工審查追蹤架構、資金流、跨函式狀態與經濟意圖。靜態分析尋找模式與資料流，但可能產生偽陽性和偽陰性。單元、整合、分叉與差異測試比較具體行為。有狀態模糊測試與不變量測試探索產生的呼叫序列，但結果取決於處理器、選擇器、種子、語料庫、執行次數、深度與建模環境。

符號執行與形式驗證可在受支援的語意和假設下確立特定斷言。求解器傳回 `unknown`、逾時或遇到不支援的行為，都不構成證明。即使性質已獲證明，也可能遺漏預言機經濟機制、治理、部署設定、鏈上行為，或團隊真正想實現的需求。規格與解讀仍由人工審查負責；AI 產生的觀察並不是獨立的保證方法。

每項發現都應指出受影響的成品與部署、前提條件、最小證明、利用路徑、可達性、所需權限、攻擊者資本、可重複性、經濟影響、嚴重度標準與修正建議。可利用性或發生可能性與影響是兩個不同面向。理論最大值、漏洞名稱或工具標籤不能證明可執行損失。

`open`、`acknowledged`、`risk accepted`、`partially fixed`、`resolved` 與 `retested` 等狀態並非通用標準。可信的結案應把原發現連結至精確修正提交，記錄已測試的變更路徑與相鄰路徑，並說明由誰在何時複測哪些項目。已接受風險仍然是風險，有限複測不會把原稽核範圍擴大至所有新增程式碼。

可升級部署需要專項核對。應解析代理、實作或信標與管理員儲存槽；驗證初始化與再初始化行為、實作合約鎖定、儲存配置相容性、升級授權、時間鎖或緊急繞過、遷移與回復。從受稽建置重現建立位元碼和執行時期位元碼，再於每條鏈上比較連結程式庫、參數、角色與已初始化狀態。

最終報告應說明修訂版、稽核人員與日期、精確範圍、方法與設定、限制、發現、證據、修正狀態、未解決或已接受風險及揭露條款。發布後應監控實作雜湊、角色、參數、相依項目與事件。任何重大變更都會產生需審查的新差異；附在舊報告上的徽章不會自動跟隨未來程式碼。

請依下列流程執行：

1. 凍結稽核清單：程式碼儲存庫、提交、相依項目、編譯器與設定、產生和部署程式碼、鏈、位址、代理架構、參數、區塊、報告修訂版、納入項目與排除項目。
2. 定義資產、參與者、特權角色、信任邊界、攻擊者能力、生命週期、排序與活性假設、外部相依項目和可衡量不變量。
3. 重現建置並梳理架構、儲存、資料、資金與控制流；核對原始碼、成品、程式庫、建立與執行時期位元碼、初始化函式、角色和正式環境部署。
4. 組合執行人工、靜態、單元、整合、分叉、差異、模糊、不變量、符號或形式化方法，並記錄工具版本、設定、種子、語料庫、涵蓋率、逾時和未知結果。
5. 記錄每項問題的受影響成品、前提、證明、可利用性、影響、嚴重度方法、部署曝險、建議與機密證據，不把工具標籤當作判斷。
6. 凍結修正提交並複測問題、相鄰路徑和不變量；驗證代理儲存、初始化、遷移、回復、可重現建置及部署收據，再賦予有證據支持的狀態。
7. 發布範圍、方法、限制與殘餘風險；將受稽成品和每條正式運作的鏈逐項核對，並隨系統變更持續更新監控、揭露、事件應變與漏洞懸賞控制。

<a id="example"></a>

## 範例

- **金庫通膨路徑需要完整帳本。** 攻擊者透過首次存入分支投入 `1 asset` 並取得 `1 share`，接著捐贈 `1,000,000 assets`；總量成為 `1,000,001 assets` 與 `1 share`。受害者存入 `500,000 assets`，不安全的向下捨入計算得到 `floor(500,000 * 1 / 1,000,001) = 0 shares`。若系統接受零份額存入，金庫會持有 `1,500,001 assets`；攻擊者贖回全部資產並獲利 `500,000 assets`，其投入為 `1,000,001-asset`。若實作會在零份額時回復交易，這條特定損失路徑便不會執行。
- **檔案涵蓋率不等於部署涵蓋率。** 清單包含 `24 source units`、`4 deployment scripts` 與 `3 keeper services`，合計 `31 items`。稽核納入 `20 source units` 和 `2 scripts`，所以按數量計算的涵蓋率為 `22 / 31 = 70.96774194%`；其餘 `9 items` 被排除。若正式環境的代理指向由排除單元建置的實作，該正式實作的涵蓋率是 `0%`，即使標題數字是 `70.96774194%`。
- **模糊測試觀察不構成不存在性證明。** 一次有狀態測試執行 `2,000 sequences * 64 calls = 128,000 calls`；不變量在 `3 sequences` 中失敗，占產生序列的觀察比例 `3 / 2,000 = 0.15%`。修正後，`10,000 sequences * 64 calls = 640,000 calls` 未出現失敗。這表示該語料庫中為零，而非證明；在獨立且產生器穩定的教學假設下，三倍法則給出的近似 `95%` 上限是每個產生序列 `3 / 10,000 = 0.03%`。
- **發現結案與部署身分彼此獨立。** 報告有 `12 findings`：`2 critical`、`3 high`、`4 medium` 與 `3 low`。複測結案 `2 + 2 + 3 + 2 = 9` 項，按數量計算的結案率為 `9 / 12 = 75%`；仍有一項高、一項中和一項低未結案。受稽執行時期雜湊為 `H1`，但正式環境實作是 `H2`，所以無論結案率如何，部署驗證都失敗。換成精確的 `H1` 並匹配代理儲存槽、初始化函式和角色，只能證明受檢區塊時點的身分一致。

<a id="risks"></a>

## 風險

- 程式碼儲存庫、提交、子模組或產生的原始碼過時或含糊。
- 編譯器版本、最佳化工具設定、程式庫或相依項目未鎖定。
- 部署腳本、建構函式資料、初始化函式或 CREATE2 salt 被排除。
- 審查了錯誤的鏈、位址、代理、信標或實作。
- 原始碼、成品、建立位元碼與執行時期位元碼無法相互核對。
- 威脅模型遺漏參與者、權限、資產或信任邊界。
- 規格或不變量使用錯誤的單位、前提條件或例外。
- 管理員、守護者、時間鎖、暫停、升級或遷移路徑被遺漏。
- 預言機、代幣、跨鏈橋、keeper、治理或鏈上假設失效。
- 靜態分析產生未經分類核驗的偽陽性。
- 人工審查、測試或模糊測試遺漏未產生的路徑。
- 模糊測試工具、選擇器、種子、語料庫、深度或狀態模型有偏差。
- 求解器逾時、不支援的語意或 `unknown` 被誤認為證明。
- 正確的證明形式化了錯誤需求或不完整系統。
- 嚴重度依據漏洞名稱，而不是可利用性與影響。
- 理論風險價值被誤認為可達損失或攻擊者利潤。
- 修正引入相鄰迴歸或破壞經濟不變量。
- 代理儲存、初始化函式、升級或遷移破壞正式環境狀態。
- 已接受、未結案或僅部分修正的問題被「通過稽核」徽章掩蓋。
- 報告被視為保險、認證、賠償承諾或永久涵蓋。

<a id="misconceptions"></a>

## 常見迷思

- **「沒有重大發現就代表合約安全。」** 這只描述有限範圍、期間與方法下報告的發現，並非所有可能缺失。
- **「測試涵蓋率高或模糊測試零失敗，就證明沒有漏洞。」** 這些只是對選定程式碼和產生路徑的量測，不是不存在性證明。
- **「形式驗證證明整個協定安全。」** 它只證明模型在假設下編碼的性質；規格和周邊系統仍可能有誤。
- **「已修正代表所有正式環境部署都已完成修補。」** 結案需要獨立複測，並逐一核對每個部署的建置、位元碼、代理、參數與角色。
- **「知名稽核機構會保證賠償或未來升級。」** 責任取決於稽核契約，使用者未必是受益人，後續程式碼或設定不在舊快照範圍內。

<a id="related"></a>

## 相關主題

- [智慧合約](/zh-tw/crypto/smart-contract/)
- [可升級合約](/zh-tw/crypto/upgradeable-contract/)
- [漏洞懸賞](/zh-tw/crypto/bug-bounty/)

<a id="sources"></a>

## 來源

- [OWASP Smart Contract Security Verification Standard (SCSVS)](https://scs.owasp.org/SCSVS/) - OWASP (查閱日期: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity (查閱日期: 2026-08-13)
- [Slither, the smart contract static analyzer](https://github.com/crytic/slither) - Crytic (查閱日期: 2026-08-13)
- [Invariant Testing](https://www.getfoundry.sh/guides/invariant-testing) - Foundry (查閱日期: 2026-08-13)
- [Certora User's Guide](https://docs.certora.com/en/latest/docs/user-guide/index.html) - Certora (查閱日期: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (查閱日期: 2026-08-13)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (查閱日期: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (查閱日期: 2026-08-13)

Source: https://wiki.fcontext.com/zh-tw/crypto/contract-audit/index.mdx