隨著 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 真正兌現其“去信任”的承諾，為自主代理的未來奠定安全基石。
