随着 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 真正兑现其“去信任”的承诺，为自主代理的未来奠定安全基石。
