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