隨著ERC-8004（Trustless Agents）標準正式部署至以太坊主網，AI Agent的身份與聲譽管理進入了一個可驗證、去信任的新階段。該標準透過三個核心註冊表：身份註冊表、聲譽註冊表和驗證註冊表，為代理商提供了鏈上可驗證的「身份系統」。本文將從安全審計視角出發，結合ERC-8004 的技術細節，剖析每個註冊表的風險要點，為開發者及審計員提供一份實用的審計指南。

技術細節與審計要點

ERC-8004的關鍵在於它的三個註冊表（Registry）：

1. 身分註冊表（Identity Registry）

基於ERC-721 的最小鏈上句柄，帶有URIStorage 擴展，解析到代理的註冊文件，為每個代理提供可攜帶、抗審查的標識符。

在ERC-8004 的架構中，身分註冊表建立在ERC-721 之上，並擴充了URIStorage 功能。換句話說，每一個代理在鏈上都對應一個獨一無二的NFT，這個NFT 稱為AgentID。

當開發者建立一個代理程式時，會呼叫註冊表合約的register 函數，鑄造一個新的AgentID。這個代幣綁定一個tokenURI，指向鏈下儲存的一份JSON 檔案——也就是所謂的「代理註冊文件」。註冊文件必須遵循嚴格規範，通常包括三類核心內容：

- 基本訊息，例如名稱、描述、頭像URL；

- 服務端點，也就是代理可以被存取的網路位址，支援HTTP、WebSocket、Libp2p、A2A、MCP 等多種協定；

- 能力聲明，即代理可執行的任務列表，例如圖像生成、套利交易或程式碼審計。

僅有自我聲明顯然不足以建立信任，因此ERC-8004 引入了網域驗證機制。代理必須在其聲明的網域下託管一份簽名文件，路徑為/.well-known/agent-card.json。鏈上註冊表會校驗這一鏈接，從而將鏈上AgentID 與對應的DNS 域名綁定。這一步的意義在於防止釣魚與冒名攻擊，代理不能隨意聲稱自己屬於某個域名，必須用加密簽名證明控制權。

審計要點：

● 檢查setTokenURI 函數的存取控制，確保僅允許代理擁有者或經過授權的角色（如onlyOwnerAfterMint）更新URI。

●檢視URI 是否支援不可變儲存方案（如IPFS、Arweave）。若採用中心化HTTP 鏈接，需評估網域控制權的安全性，防止DNS 劫持。

● 驗證URI 格式的合法性，避免由空指標或無效URI 所導致的合約異常。

● 驗證合約是否在校驗網域簽署時嚴格執行加密簽章驗證（如EIP-712），防止簽章偽造或重播攻擊。

● 檢查網域所有權證明的過期機制，防止長期有效的簽名被重複使用。

● 確保網域解析過程不依賴中心化預言機，避免單點故障或操縱。

2. 聲譽註冊表（Reputation Registry）

用於發布和獲取回饋訊號的標準介面。評分和聚合既發生在鏈上（可組合性）也在鏈下（複雜演算法），使得代理評分、審計網絡和保險池的專業服務生態系統得以實現。

用於對已經註冊的AI Agent進行評估回饋。鏈上進行簡單的回饋提交，鏈下可拓展進行複雜的，聚合後上鍊。

ERC-8004 還可以透過「支付證明掛鉤」（Payment-Proof Linking）機制來防止惡意刷評分。 當代理A 完成對代理B 的評價時，呼叫giveFeedback 函數。 此函數不僅接受評分（0-100）和評論哈希，還允許傳入一個paymentProof 欄位，通常是x402 交易的雜湊值。讓刷評估的成本變得極高，大幅降低女巫攻擊的可能性。 最終，整個系統會自然地獎勵表現穩定、品質高的代理。

審計要點：

●驗證giveFeedback 函數是否強制要求paymentProof 參數，並檢查該參數是否為有效的x402 交易雜湊（或符合其他付款標準）。應確保支付證明不可重複使用（如記錄已使用的雜湊），防止單次支付多次評估。

● 檢查評分範圍（0-100）是否在合約層級強制約束，避免超出邊界的評分破壞聚合邏輯。

● 評估鏈下聚合演算法的抗操縱性：例如是否採用中位數、修剪極端值或加權平均，是否對異常行為（如短時間內大量評價）進行懲罰。

● 審查罰沒條件是否清晰且可驗證，例如是否依賴鏈上證據或第三方預言機提交詐欺證明。

● 確保罰沒邏輯不包含中心化特權（如管理員可隨意沒收質押金），罰沒觸發條件應完全由智能合約自動執行。

● 測試質押金提取的鎖定期與條件，防止代理人在面臨罰沒前緊急提領資金。

3. 驗證註冊表（Validation Registry）

用於請求和記錄獨立驗證者檢查的通用鉤子（例如，zkML 驗證器、TEE oracle、可信任評判）。

聲譽反映的是過去，但在高風險情境中（如大額資金調度），單靠歷史還不夠。 驗證註冊表允許代理將成果提交給第三方或自動化系統驗證，可以使用如質押安全推理重執行、zkML 驗證器或TEE 預言機來驗證或拒絕請求。

第一種模型是加密經濟驗證，基於博弈論的安全設計。 代理必須在註冊表中質押一定數量的原生代幣或穩定幣。 如果代理商未能履約或提供錯誤結果，驗證者網路可以提交詐欺證明，觸發智慧合約自動罰沒其質押金。 這種模型適用於結果易於驗證但計算過程不透明的任務，例如資料抓取或簡單的API 服務。

第二種模型是密碼學驗證，基於數學原理的安全設計。 TEE 認證（Trusted Execution Environment）讓代理程式在安全加固的硬體環境中運行，例如Intel SGX 或AWS Nitro。 驗證註冊表可以儲存並驗證來自硬體的遠端認證報告，證明該代理程式運行的程式碼確實是未被篡改的特定版本。

zkML（零知識機器學習）是另一種密碼學驗證方式。代理在提交推理結果的同時，提交一個零知識證明。 該證明可以被鏈上的驗證合約以極低成本驗證，數學上保證該輸出確實是由特定模型（如Llama-3-70B）在特定輸入下產生的。 這可以防止「模型偷換」攻擊，即服務提供者宣稱使用高端模型但實際使用低階模型以節省成本。

審計要點

若為加密經濟驗證，需檢查：

● 檢查詐欺證明的提交窗口期：是否給驗證者足夠的時間發現並提交證明？窗口期過短可能遺漏惡意行為，過長則導致資金長時間鎖定。

● 驗證詐欺證明的裁決邏輯：是否依賴多簽驗證者集合？若是，需審查驗證者選取的去中心化程度和閾值設定；若完全鏈上裁決，需確保裁決依據（如鏈上可驗證的結果）存在且無歧義。

● 確保質押金數量與風險匹配，防止低成本的惡意行為（如質押過少，作惡收益遠大於損失）。

若為TEE認證，需檢查：

● 檢查合約是否驗證TEE 證明的時效性（如包含時間戳記或區塊高度），防止過期證明被接受。

● 驗證證明內容是否包含代理人的程式碼雜湊、輸入輸出摘要，確保證明與特定任務綁定，避免跨任務重複使用。

● 評估TEE 證明的驗證邏輯是否依賴外部預言機（如Intel IAS），若依賴，需審計預言機的安全性和去中心化程度。

若為zkML驗證，需檢查：

●確認合約整合了經過審計的zk 驗證庫（如SnarkVerifier），並針對特定證明系統（如Groth16、PLONK）正確配置驗證金鑰。

● 檢查驗證合約是否限制證明適用的模型和輸入範圍，防止模型偷換攻擊（例如證明是針對小模型生成，卻聲稱是大模型輸出）。

● 評估證明產生的去中心化程度：是否依賴單一證明者？若存在多個證明者，需設計共識機制防止惡意證明者。

結語

ERC-8004 為AI Agent 的信任建立提供了標準，其安全性是整個鏈上Agent生態的關鍵。安全審計工作需深入理解三個註冊表的設計意圖與潛在風險。此外，跨合約互動的複雜度與常規漏洞也不容忽視。需透過全面、嚴謹的審計確保ERC-8004 真正兌現其「去信任」的承諾，為自主代理的未來奠定安全基石。